I fall more in Matthew side of this regarding sealed by default.<br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 9, 2016 at 12:29 PM Matthew Johnson 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 Jul 9, 2016, at 11:04 AM, Tino Heth <<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>> wrote:<br>
><br>
><br>
>> Of course it can be done either way. But there are significant ecosystem robustness advantages to making sealed the default and comparatively few downsides. Most libraries are open source (so can be modified directly or via PR if necessary)<br>
> First:<br>
> The claim about robustness sounds like a fact, despite being just an opinion (feel free to correct me if you have any evidence at all). We should stay honest with our predictions.<br>
> Second:<br>
> Do you really believe there will be positive impact on open-source libraries?<br>
> My forecast is that closed by default will dramatically increase trivial pull request where developers ask for unsealing so that they can do as they like…<br>
<br>
I think this is a good thing. It will force a considered answer and a discussion about whether or not subclassing should be supported by the library.<br>
<br>
> and I've no idea why somebody could come up with the idea that forking is desirable.<br>
<br>
Forking is desirable if your goals, needs, values, etc are substantially different than the library author such that you do not agree on what the API contract should look like.<br>
<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>