<div dir="ltr"><span style="font-size:12.800000190734863px">&gt; What is your evaluation of the proposal?</span><br style="font-size:12.800000190734863px"><br><div>Strong -1 from me.<div><br></div><div>I agree that subclassing library classes that were not explicitly planned to be subclassed might sometimes lead to bugs. But just because a technique or feature of a language allows you to sometimes make mistakes, it doesn&#39;t mean it should be completely disallowed. By this logic, we&#39;d have to remove all instances of &quot;!&quot; any anything related to pointers from Swift. It&#39;s possible for a feature to allow you to shoot yourself in the foot, and still be useful at the same time.</div><div><br></div><div>We&#39;ve removed things like C-style for loops or &quot;if object {&quot; shorthand from Swift, because we have cleaner ways of achieving the same goals in a different way, so it was safe to remove them without making the language less powerful. But here we would be removing a feature for which there is no workaround. If I need to override some methods from a binary library or SDK that I use in my app (e.g. Crashlytics, Zendesk - yes, these are ObjC libraries, but I&#39;m speaking about the future), in order to work around some bugs, customize or adapt the behavior to my app (e.g. UI styling, copywriting, i18n), then there&#39;s no other way to do achieve this, other than rewriting the whole thing from scratch. Even if I do have access to the source code, keeping your extensions in a subclass in your app is a much cleaner solution that hacking the library code directly (and getting merge conflicts later). One day, Apple system frameworks will also be written in Swift, and this change will make it harder to use them.</div><div><br></div><div>Of course, the above is only a problem if the class hasn&#39;t been marked as subclassable. But I&#39;m afraid that in most cases it won&#39;t be, even if it could be, simply because:</div><div><br></div><div>1) the author hasn&#39;t foreseen I&#39;d need this (how could they foresee every possible use case and requirement? if they had known what I&#39;m going to need, I wouldn&#39;t need to write a subclass in the first place)<br></div><div><br></div><div>2) or, more likely, they just didn&#39;t remember about this feature or didn&#39;t realize at all that they need to add this subclassable keyword to make this possible. Or they did, but they forgot to add it to some new code.</div><div><br></div><div>The proposed &#39;subclassable&#39; and &#39;overridable&#39; keywords would also introduce a lot of noise to the library code, if the author wanted to make most or all of their code extensible. A single &#39;open&#39; keyword would be preferred, and adding it only to the class and not the methods (marking class as open makes whole class and its methods non-final) would be even better, since it would make it more likely library authors would actually use it (though still only a &quot;lesser evil&quot;).</div><div><br></div><div>As for the performance aspect - I don&#39;t think a minor speedup should be a reason to remove a useful feature from the language, it would be most likely a case of premature optimization. If necessary, you can always mark a critical class as final if profiling shows that it&#39;s being called all the time, and leave all the other classes open by default.</div><div><br></div></div><div><br></div><div><span style="font-size:12.800000190734863px">&gt; Is the problem being addressed significant enough to warrant a change to Swift?</span></div><div><br></div><div>I don&#39;t think the problem is significant, and I&#39;m afraid the proposed solution is worse than the problem itself.</div><div><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">&gt; Does this proposal fit well with the feel and direction of Swift?</span></div><div><br></div><div>I don&#39;t feel qualified to answer this.</div><div><br><span style="font-size:12.800000190734863px">&gt; If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">I&#39;ve used Ruby and JavaScript for many years each, and ObjC for a few years. In my opinion, all three give the developer much more power when it comes to using code in creative and unplanned ways when that&#39;s what you need to achieve your goals, than Swift does currently. That&#39;s especially the case with the first two - ObjC already felt too restrictive in many ways for me.</span></div><div><br></div><div><span style="font-size:12.800000190734863px">&gt; How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br style="font-size:12.800000190734863px"></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">I&#39;ve read the proposal and skimmed through the responses thread.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Kuba</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div>