<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><span></span></div><div><div>I have been following the discussion and reading the arguments in favor and against. I think I understand both sides better now. <br><br>If this proposal is accepted I hope some more thought is given to the naming. </div><div><br></div><div>I would like to echo what others have said regarding the names. In particular I am still not sure about subclassable and overridable implying public. I think it would be more clear to to read "<b>public subclassable class C</b>". <br></div><div><br></div><div>I have these thoughts regarding the naming:</div><div><br></div><div>I think that subclassable could be implied when the class contains an overridable method or property. In other words, does it make sense to have an overridable method or property when the class is not subclassable? Oh, I just realized that it is more clear if it is expressed explicitly. It could also avoid making the mistake of making a class subclassable by accident. </div><div><br><div>Also "subclassable class" sounds a bit redundant. In other words, I think subclassable implies it is a class. But I am not sure I would want to leave out the class part, which brings me to one of the other alternatives:<br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">public open class C</div><div id="AppleMailSignature">public open func / var</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">The pros here are that is is more concise. The public part could be left out because open seems to imply public. Open also suggests that it may be subclassable/ overridable. On the other hand subclassable/ overridable are both very clear though. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Thanks</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div>On 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><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>On Jul 9, 2016, at 11:04 AM, Tino Heth <<a href="mailto:2th@gmx.de">2th@gmx.de</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>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)</span><br></blockquote></blockquote><blockquote type="cite"><span>First:</span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span>Second:</span><br></blockquote><blockquote type="cite"><span>Do you really believe there will be positive impact on open-source libraries?</span><br></blockquote><blockquote type="cite"><span>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…</span><br></blockquote><span></span><br><span>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. </span><br><span></span><br><blockquote type="cite"><span>and I've no idea why somebody could come up with the idea that forking is desirable.</span><br></blockquote><span></span><br><span>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.</span><br><span></span><br><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></body></html>