[swift-evolution] [Proposal] Sealed classes by default

Wed Jun 29 18:16:29 CDT 2016

> On Jun 29, 2016, at 4:05 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jun 29, 2016, at 5:56 PM, Mark Lacey via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> From my understanding, "Sealed" or whatever we will call it technically provides no actual optimisations. We cannot assume the class is final because something inside the module may have vended a subclass.
>> 
>> It can enable optimization when compiling with -whole-module-optimization since we know all the subclasses defined within the module. For any call site where the static type and all subclasses are sealed, we can limit the set of potential callees to only the functions defined in those types. Further, if the static type at the callsite has no subclasses, we can treat it like final and devirtualize the call.
> 
> There are other interesting things that you can do when you know a class isn’t public inheritable.  For example, I am planning a proposal (after Swift 3) for exhaustive pattern matching on classes that are not publicly inheritable.  

Yes, there are a number of things in this category.  For example, there's a fair amount of pedantry around class initializers that we could significantly weaken if we're certain we know about all the subclasses.

John.

> 
>> 
>> Mark
>> 
>>> 
>>> The issue that "sealed" as a concept fills is that you stop people from subclassing types that were never specifically designed for subclassing, but allows the module to do some subclassing for its own needs because the developer understands how the class works.
>>> 
>>> It also means a developer of the framework can retroactively apply "Final" to the class if they've worked out it actually should be final and will never be subclass. If the concept of Sealed did not exist, then a framework could never finalise a class down the track - users of the framework may have subclassed the type, and now the framework is hamstrung by its previous "openness".
>>> 
>>> Should this be the default? In my opinion, yes.  Allowing subclassing to other clients should be explicit. It will tie you down and limit you from developing into the future. Allowing subclasses from other clients is a promise for the life of your product, and cannot be reneged. On classes that are not designed for subclassing, this is ill advised, and on classes you wish to optimise, it's a permanent limitation.
>>> 
>>> While I fear the abuse framework vendors will exercise, by allowing clever private hacks, and disallowing obj-c style workarounds, I think the safety and longevity of this approach is far more important.
>>> 
>>> +1 to the concept. I agree "sealed" is not foot wording and can be improved.
>>> 
>>> - Rod Brown
>>> 
>>>> On 30 Jun. 2016, at 5:05 am, Michael Peternell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> I'm still unhappy about this "sealed by default" proposal. That really looks like premature optimization to me. Instead there should be some `sealed` keyword. Maybe it should be called `applepublic` :-p Everyone will understand!
>>>> 
>>>> `sealed` classes should be a special optimization used by optimizing developers who ask for it. Don't make it an unwanted and un-asked-for default optimization. The people who care for optimization much will learn about `sealed` and be able to apply the concept in both cases. The people who don't care about performance will just be disappointed by the "implicitly sealed" behavior. And with this proposal, when I read `unsealed` I can never know: "did this developer intend me to be able to subclass this class? or did he just not want to restrict me unnecessarily?" The documenting aspect of `unsealed` is so small.
>>>> 
>>>> And `sealed` is just an optimization; IMHO the magic of static dispatch lies in final classes or final methods. Sealing everything by default just marks many classes and methods as implicitly final (because it can be proven that they are not subclassed). I just don't think that all these theoretical performance improvements are really worth the trouble in practice.
>>>> 
>>>> -Michael
>>>> 
>>>>> Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>>> 
>>>>> How about `public(extensible)` ?
>>>>> 
>>>>> On 29.06.2016 21:32, John McCall via swift-evolution wrote:
>>>>>>> On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really make sense. `internal` declarations are always sealed.
>>>>>> 
>>>>>> Right.
>>>>>> 
>>>>>> If "sealed" is the default behavior for public classes and methods — and I don't think the modifier is worth adding unless it's the default — then we need a way of "unsealing" classes and methods that's fairly pithy.  I don't think a parenthesized spelling is good enough for that.  And we should try to make the positive form ("can be overridden") shorter than the negative ("cannot be overridden"), because the latter will not usually be written.
>>>>>> 
>>>>>> To me, the ideal spelling would be usable in place of "public".  If it does have to be stacked with "public", then I think it ought to be pretty short.
>>>>>> 
>>>>>> "communal"? :)
>>>>>> 
>>>>>> "open" doesn't carry quite the right meaning, and it would need to be paired with "public", I think.
>>>>>> 
>>>>>> John.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> -Michael
>>>>>>> 
>>>>>>>> Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>>>>>> 
>>>>>>>> Do we really need a new keyword? Since we already have syntax like `internal(set)` couldn't we do `internal(unsealed)`, etc.
>>>>>>>> 
>>>>>>>>> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell <michael.peternell at gmx.at <mailto:michael.peternell at gmx.at>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>>>>>>>> 
>>>>>>>>>> +1 for the concept of a "sealed” class.
>>>>>>>>>> -1 for making it default.
>>>>>>>>> 
>>>>>>>>> Aren't sealed classes already implemented? I think the keyword is `final`..
>>>>>>>>> So there is nothing left to do :)
>>>>>>>> 
>>>>>>>> No, `final` doesn’t allow for any subclassing, but `sealed` allows for subclassing within your module (where you can presumably write more efficient code based on knowledge of each subclass).
>>>>>>>> 
>>>>>>>> - Dave Sweeris
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution at swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/7462f6bf/attachment.html>