<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I think sealing classes already existi in Swift it's called Private :)</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Head of Trolls</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On 12 July 2016 at 12:20, Charlie Monroe via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 12, 2016, at 11:12 AM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> With all the controversy around proposal 0117, I thought I would take a stab at an alternative approach that attempts to balance the concerns of both sides of the argument. I don’t know that it would be everyone's first choice, but I think/hope it would be acceptable to the vast majority.<br>
><br>
> Take a look here and let me know if you think it is worth flushing out:<br>
> <a href="https://gist.github.com/jonhull/a5ac84a16b7a0ffc0c00747998f390d9" rel="noreferrer" target="_blank">https://gist.github.com/jonhull/a5ac84a16b7a0ffc0c00747998f390d9</a><br>
><br>
><br>
> The basic idea (for those who hate clicking links) is to create 3 levels of extensibility:<br>
> • Open - The class or method is open to be extended through subclassing/override.<br>
> • Sealed - Attempting to subclass/override the class/method will result in a compiler error saying that it is not intended to be extended. Using the ‘unsafe' keyword will allow compilation.<br>
> • Final - The class or method can not be subclassed/overridden. Attempting to do so will result in a compiler error.<br>
><br>
> These would be orthogonal to access modifiers. Thus you would write ‘public open’, which is admittedly two words… but together they are actually shorter than the single ‘subclassable’ keyword<br>
><br>
> You can also specify different levels of extensibility at different levels of visibility (e.g. ‘public final internal(open)’)<br>
><br>
> The default would be ‘sealed internal(open)’ which means it is publicly sealed, but open within the defining module. This is similar to the default of 0117, except it allows overriding using the ‘unsafe’ keyword (where the user explicitly acknowledges that subclassing/overriding is not supported by the API).<br>
<br>
</span>This not only looses some of the whole-module optimization benefits but also renders many other future proposals moot. For example the exhaustive switch based on a sealed class:<br>
<br>
let x: MySealedClass = ...<br>
switch x {<br>
case let obj as X:<br>
...<br>
case let obj as Y:<br>
...<br>
}<br>
<br>
where X and Y are subclasses of MySealedClass. The benefit of this is no "default" case and a compile-time check that all the cases are handled, just like with an enum (since the class is sealed, the compiler knows all possible cases). You can probably imagine how would this get broken when if you used "unsafe" subclassing.<br>
<br>
Sure, there could be an implicit default: fatalError("You've subclassed what should never have been subclassed."), but it just doesn't feel right.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thus, we lose some compiler optimizations in the default case (vs 0117), but these can easily be regained by explicitly marking parts of the API as final. The semantic meaning of the 0117 default is kept, with an escape hatch for problematic API. Thoughtful framework writers would go through and mark API as either ‘public open’ or ‘public final’. Less thoughtful framework authors would still get feedback asking them to do so, since nobody likes having the word ‘unsafe’ in their code when they don’t have to.<br>
><br>
> This design feels much Swiftier™ to me because it has opt-out safety and opt-in risk. It protects you from accidentally causing trouble, but gets out of your way when you tell it you know what you are doing.<br>
><br>
> Thoughts?<br>
><br>
> Thanks,<br>
> Jon<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">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>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br></div>