> On Jun 29, 2016, at 5:56 PM, Mark Lacey via swift-evolution > <[email protected]> wrote: > >> >> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution >> <[email protected] <mailto:[email protected]>> 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. > > 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 >>> <[email protected]> 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 >>>> <[email protected]>: >>>> >>>> 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 >>>>>> <[email protected]> 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 >>>>>>> <[email protected]>: >>>>>>> >>>>>>> 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 >>>>>>>> <[email protected]> wrote: >>>>>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >>>>>>>>> <[email protected]>: >>>>>>>>> >>>>>>>>> +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 >>>>>>> [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 >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
