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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
