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

Xiaodi Wu xiaodi.wu at gmail.com
Sun Jul 17 15:14:54 CDT 2016

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>

More information about the swift-evolution mailing list