<div dir="ltr">I too would be interested in this info. Brent&#39;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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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&#39;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>