<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><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote><div><br class=""></div><div>+1 </div><div>In its third revision I like this proposal more. I think “open” is a good keyword for both members and classes. </div><div>I’m in favor of the first design for open classes. That said, I also acknowledge that subclassing without overriding anything doesn’t suffer from the problems that overriding members do. Additionally, even for a sealed class, new methods could be added thought extensions. This means the the benefits of the first design over the second one are fairly small. However, in my experience (which might be wrong), designing a class for subclassing <i class="">without</i> any overridable methods is quite uncommon, and in the first design can easily be resolved by making it open. I see it as a benefit of the first design that it allows for this distinction (a class <i class="">can</i> be make public without being subclassable).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></blockquote><div><br class=""></div><div>I’ve encountered virtual functions in C++ but only to a small extent.</div><div><br class=""></div><div>I like this solution better because it makes the distinction between internally and externally overridable (and gets out of the way for internal overrides).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div></blockquote><div><br class=""></div><div>Read the proposal and much of the discussion (but not all, there’s been so much 😉)</div><div><br class=""></div>- David<br class=""><br class=""></div></body></html>