<div style="white-space:pre-wrap">Well stated and has pushed me into favoring the closed be default case. I favor being explicit and the default being safe (you can always unseal in a future revision if a need arises).<br><br>Also as you note it won't prevent bad implementations but it will help library developers better bound their external surface and contract...which if leveraged well will help with robustness, testability, and flexibility in future revisions.<br><br>-Shawn</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 10, 2016 at 10:53 PM Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 2. The motivation seems to be that it will force better API design.<br>
<br>
No, that wasn’t my motivation in giving it a +1. This seems to be a common misunderstanding in the “no” camp, so I’ll address it.<br>
<br>
Accepting this proposal won’t turn bad API designers into good ones. Crappy APIs are still going to be crappy with or without this. In the immortal quote apparently due to Lawrence Flon: “There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code.”<br>
<br>
The justification for this proposal is all about supporting the people who are working to design library APIs right, and about maintaining consistency with the design philosophy of Swift. To wit: in Swift, where there’s a default choice, it’s the safe one; where there’s a consequential design decision, it’s explicit.<br>
<br>
Rod Brown hit the crux of it: sealed → open is safe for existing API clients, but open → sealed is a breaking change. “Sealed” is thus the safer choice, and “open” is a consequential design decision. Given the general precedent and philosophy of Swift, competent API designers might reasonably be taken aback that open is the default. In fact, given the habit Swift encourages of leaning on compiler verification, this is a potential source of designer error.<br>
<br>
• • •<br>
<br>
For those who think that discouraging inheritance by default is something recent, or a fad, or a quirk of Swift: Josh Bloch spent over 5 pages of Effective Java arguing against “subclassable just in case.” That was in 2001, and it was old news even back then.<br>
<br>
Those looking for a more detailed analysis of the problems caused by APIs allowing inheritance without designing for it should read his analysis. It’s 15 years old, it’s Java, but it still stands. (He even gives instructions toward the end for simulating something very much like the here-proposed “sealed” in Java using package-private initializers.) It’s item 15 in the book, “Design and document for inheritance or else prohibit it.”<br>
<br>
Cheers,<br>
<br>
Paul<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>