<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jul 21, 2016 at 8:33 AM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Swift community,<br>
<br>
The third review of "SE-0117: Allow distinguishing between public access and public overridability" begins now and runs through July 25. The proposal is available here:<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a><br>
<br>
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
or, if you would like to keep your feedback private, directly to the review manager.<br>
<br>
What goes into a review?<br>
<br>
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br>
<br>
* What is your evaluation of the proposal?<br></blockquote><div><br></div><div>+1 to the first design. I wouldn't be upset if the second design was what got accepted, but I strongly prefer the first.</div><div><br></div><div>One of the benefits of this proposal has been formalizing some software design notions related to type extensibility, and I feel very strongly that API authors should be forced to make a decision one way or the other at the time that they design a class whether it is extensible or not. It's true that under design #2 you get a closed class (module extending with data) without the explicitness of the keyword. However, being able to look at a class definition and know immediately whether it's intended to be open or closed is even more important. The performance improvements also seem compelling.</div><div><br></div><div>While the formal side of me really liked keeping orthogonal concepts (visibility vs. extensibility) separate, I can appreciate the desire to eliminate boilerplate. Having "open" imply "public" unless stated otherwise seems like a reasonable compromise.</div><div><div><br></div><div>Likewise, open-within-a-module-and-closed-outside as the default for "public" is entirely aligned with Swift's other default visibility, internal-by-default. The credo is essentially "don't protect users from themselves and don't make coding more difficult for the common case of within-app/module development, but the minute you decide to expose something for other users, you must think about these things that affect how others can and will use it."</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div><br></div><div>Yes. More mainstream languages need to do more to encourage authors to think about their designs and to allow those who care deeply about API design to express them well.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Does this proposal fit well with the feel and direction of Swift?<br></blockquote><div><br></div><div><span style="line-height:1.5">Yes.</span><br></div><div><span style="line-height:1.5"><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></blockquote><div><br></div><div>Read the original and latest proposals and followed the discussions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
More information about the Swift evolution process is available at<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
<br>
Thank you,<br>
<br>
-Chris Lattner<br>
Review Manager<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>