[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly
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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution