> On Jun 29, 2016, at 4:05 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: >> On Jun 29, 2016, at 5:56 PM, Mark Lacey via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell >>>>>>>>> <michael.petern...@gmx.at <mailto:michael.petern...@gmx.at>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> swift-evolution@swift.org >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
