<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><b class="">What is your evaluation of the proposal?</b></div><div class="">I think the philosophical direction of the proposal is good, though I still don’t like the actual implementation details. There are two concepts here:</div><div class=""><ul class="MailOutline"><li class="">the ability to subclass</li><li class="">the ability to override members</li></ul><div class=""><br class=""></div></div><div class="">Having both of these concepts annotated with `open` is confusing as they do different things. Marking a class as open does **not** provide the ability to override. However, marking a member as `open` would provide the ability to override. These are two related but different concepts.</div><div class=""><br class=""></div><div class="">I see no reason why `virtual` should not be used to mark members that are inheritable and overridable. That concept is what is taught in schools, that concept is what is easily searchable, and that term is well known in the computer science field for this very concept. Just do a Google search between “open function” and “virtual function”. Deviating from this seems to be counter to one of Swift goals of being approachable. Having to learn `open` here is just mental noise that makes the coder have to think, “right… this is just a virtual method”.</div><div class=""><br class=""></div><div class="">To me, the better approach is:</div><div class=""><ul class="MailOutline"><li class="">change `open` to `virtual`</li><li class="">`virtual` is only allowed on inheritable and overridable members (i.e. `var`, `func`, and `subscript`)</li><li class="">`virtual` is not permitted on declarations that are explicitly `final` or `dynamic`. (Note that it's okay if one or both of the modifiers are implicitly inferred.)</li><li class="">A class is made inheritable outside of the module the **only** when the class is marked as both `public` and one or members are marked as `virtual` </li></ul><div class=""><br class=""></div></div><div class="">Lastly, it’s almost certainly a bug in your code if you mark a member as `open` on your public class but forget to annotate your class also with `open`. Worse, this error will **only** be caught if you attempt to use this type **outside** the context of tests because `@testable` will grant your module the `open` class state because `@testable` is special.</div><div class=""><br class=""></div><div class="">The only scenario that this change doesn’t allow would be the ability to subclass a class that has no virtual members. In my opinion, this scenario is better handled via extensions anyway.</div><div class=""><br class=""></div><div class="">However, **if** this scenario really was desirable, this could later be added by allowing `virtual` (or `inheritable` or `open`...) on a class definition. However, I would still make the argument that once you have a `virtual` member on a type, that the class is implicitly marked as `virtual` as well (see reasoning above).</div><div class=""><br class=""></div><b class="">Is the problem being addressed significant enough to warrant a change to Swift?</b><br class="">Yes<div class=""><br class=""><div class=""><b class="">Does this proposal fit well with the feel and direction of Swift?<br class=""></b>Yes</div><div class=""><br class=""></div><div class=""><b class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></b>Yes, many. This proposal’s philosophical direction is more resilient by default.</div><div class=""><br class=""></div><div class=""><b class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b></div><div class="">I’ve read the posts, thought about it, experimented, blogged about it.</div><div class=""><br class=""></div><div class="">-David</div></div></body></html>