I think sealing classes already existi in Swift it's called Private :) *___________________________________*
*James⎥Head of Trolls* *[email protected] <[email protected]>⎥supmenow.com <http://supmenow.com>* *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 12 July 2016 at 12:20, Charlie Monroe via swift-evolution < [email protected]> wrote: > > > On Jul 12, 2016, at 11:12 AM, Jonathan Hull via swift-evolution < > [email protected]> wrote: > > > > 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. > > > > Take a look here and let me know if you think it is worth flushing out: > > https://gist.github.com/jonhull/a5ac84a16b7a0ffc0c00747998f390d9 > > > > > > The basic idea (for those who hate clicking links) is to create 3 levels > of extensibility: > > • Open - The class or method is open to be extended through > subclassing/override. > > • 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. > > • Final - The class or method can not be subclassed/overridden. > Attempting to do so will result in a compiler error. > > > > 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 > > > > You can also specify different levels of extensibility at different > levels of visibility (e.g. ‘public final internal(open)’) > > > > 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). > > 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: > > let x: MySealedClass = ... > switch x { > case let obj as X: > ... > case let obj as Y: > ... > } > > 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. > > Sure, there could be an implicit default: fatalError("You've subclassed > what should never have been subclassed."), but it just doesn't feel right. > > > > > 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. > > > > 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. > > > > Thoughts? > > > > Thanks, > > Jon > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
