<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span style="background-color: rgba(255, 255, 255, 0);">* What is your evaluation of <a href="x-apple-data-detectors://4" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="misc" x-apple-data-detectors-result="4" style="-webkit-text-decoration-color: rgba(0, 0, 0, 0.258824);">the proposal</a>?</span></div><div id="AppleMailSignature">+1 for option 1.</div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">* Is the problem being addressed significant enough to warrant a change to Swift?</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Yes, accidental or thoughtless exposure of non-final classes from 3rd party libraries are something worth addressing.</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br>* Does this proposal fit well with the feel and direction of Swift?</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Yes. Having the privilege of working on a mature, pure Swift app, I can say that both code reuse and polymorphism can and should be better achieved without class inheritance (or classes at all, most of the time).</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">As alluded in the motivation section of the proposal, a third party Swift library down the line would mostly provide struct/enum types for users. Classes may be included to provide objects with reference semantics, these would be marked final by a responsible author today. And then, we have rare cases where inheritance is intended to provide customization and code reuse. The change in this proposal is sensible both for responsible library authors (who would stop worrying about missing `final`s), and for sloppy authors (who now are forced think about the interface of the library more). Ultimately, we'll get better libraries (to an extent) and happier users.</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">That's a direction I'd like Swift to go.</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">No.</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span></div><div id="AppleMailSignature">Read all 3 versions and all discussions on this list. Also followed a lot of related threads on Twitter. Had quite a few discussions of it with ppl smarter than me IRL.</div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Jul 21, 2016, at 8:33 AM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span> * What is your evaluation of <span>the proposal</span>?</span><br><span> * Is the problem being addressed significant enough to warrant a change to Swift?</span><br><span> * Does this proposal fit well with the feel and direction of Swift?</span><br><span> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br><span> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span></div></blockquote></body></html>