IMO the issue with the argument that we wouldn't be able to "monkey patch" things on sealed classes is that that is already the nature of Swift. The designer of an API can choose to use structs instead of classes, and then there's already no way to "subclass". Moreover, "final" already exists, and whether sealed is introduced or not, and whether it becomes the default or not, API designers are already free to use final in all classes they do not intend to be subclassed, so I think that would be an argument against final existing in the first place, and that ship has already sailed. <br><br>As for whether sealed would allow for optimizations: my hunch is that it would. However, as I write this I noticed a flaw with my proposal: I said that sealed classes would be exported as final. This is only half-true. They would in that they can't be subclassed outside the module, but there could be subclasses in the same module! That means if the parent were to be treated as final, code outside the module would incorrectly devirtualize non-final methods. <br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 28, 2016 at 7:59 AM Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>><br>
>>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> -1 for the fact that if all devs can write working code, fewer can do it in a clear structured fashion that is well designed for extensibility.<br>
>><br>
>> This sounds more like an argument for having sealed classes than not. As the proposal points out in the motivation, if the base class is not designed with subclassing in mind then overriding methods can result in unintended behavior (e.g. crashing, or other bugs).<br>
><br>
> But I think the counter argument is, what if you need to fix or workaround unintended behavior of the class you’re trying to use?<br>
<br>
Typically you modify something open source - 99% of which is on GitHub. IMHO the best way is to either fork it and perhaps submit a pull request with the fix.<br>
<br>
But I understand that this is not always possible...<br>
<br>
<br>
><br>
> l8r<br>
> Sean<br>
><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>
<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>
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">Javier Soto</div></div>