<div dir="ltr">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?<div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 17, 2016 at 2:14 PM, Garth Snyder via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there a summary somewhere of the motivation for allowing methods to be declared non-overridable within open classes?<br>
<br>
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.<br>
<br>
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.<br>
<br>
Garth<br>
<div><div><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>