<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><b>What is your evaluation of the proposal?</b></blockquote><div><br></div><div>Strong +1 to either design, and neutral between them.</div><div><br></div><div>In the prior review I advocated that `open` should *only* apply to classes, not members. This new proposal turns that on its head and is *vastly superior*. Tagging open members with *just* the word `open`, eliding `public` entirely, is a phenomenal improvement.</div><div><br></div><div>Kudos to the core team both for crafting this solution, and more importantly for conducting the (lengthy!) review process with such aplomb. It would have been easy (and tempting!) to end the first review by “accepting with revision”, leaving us with needless boilerplate and a suboptimal design. By instead inviting the community to bikeshed a second time *with the constraint that `sealed` would be the default*, and then meeting afterward to thoroughly discuss the possibilities, the core team has truly demonstrated how an *ahem* open, public design process ought to be carried out.<br></div><div><br></div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><b>Is the problem being addressed significant enough to warrant a change to Swift?</b></blockquote><div><br></div>Honestly I am not in a position to say.</div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><b>Does this proposal fit well with the feel and direction of Swift?</b></blockquote><div><br></div>Well, the one aspect I am not sure about is, “A class member that overrides an open class member must be explicitly declared open unless it is explicitly final or it is a member of a final or non-public class. In any case, it is considered open.”</div><div><br></div><div>This seems like an unnecessary restriction. Perhaps I want to override an `open` member with a `public` one. As in,</div><div><br></div><div>open class Base { open var x: Int { return 6 } }</div><div>open class Sub: Base { public var x: Int { return 7 } }</div><div>open class Grand: Sub { final var x: Int { return 8 } }</div><div><br></div><div>Note that “Sub” might be defined in a separate module from “Base”, a module that wants to publish Sub and Grand without letting its own clients override `x` from them.</div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><b>If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b></blockquote><br></div><div>Only languages with run-of-the-mill access control, nothing like this!</div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><b>How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">I read all messages in the previous draft and review threads, and the entire new proposal except for the 8-paragraph, 886-word “Motivation” section. Seriously, that is 3½ pages of motivation!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nevin</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 11:33 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);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>
* Is the problem being addressed significant enough to warrant a change to Swift?<br>
* Does this proposal fit well with the feel and direction of Swift?<br>
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<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><br></div></div></div>