[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu]

I too would be interested in this info. Brent's numbers look daunting
indeed (nearly 2000 annotations for methods and properties in
corelibs-foundation alone). What use cases are supported by
sealed-but-not-final public methods in open classes?


On Sun, Jul 17, 2016 at 2:14 PM, Garth Snyder via swift-evolution <
swift-evolution at swift.org> wrote:

> Is there a summary somewhere of the motivation for allowing methods to be
> declared non-overridable within open classes?
>
> I’m not asking about any particular syntax or default, just why you'd want
> this facility at all. The proposal doesn’t mention this, and the discussion
> of the initial version never really seemed to reach the issue, either.
>
> I can see that there’s a potential for static dispatch on non-overridable
> methods when called from outside the module. But presumably there’s an
> architectural argument in favor of this restriction as well.
>
> Garth
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160717/ea14a729/attachment.html>