<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Mar 26, 2017, at 08:50, David James via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><div class="">• What is your evaluation of the proposal?<br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">-1 as written (see below)</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">Not as written</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">• Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">It does in terms of apparent simplicity, but not in terms of practicality. I like to think of Swift as a practical language that does not sacrifice utility for apparent simplicity.</div></div><div class=""><br class=""></div></blockquote><div class=""><div class="">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">Can’t be compared. Swift has already set a precedent by making “private” mean something non-traditional (pre SE-0025), and I think it was a good decision, taking us away from the idea that private is only useful with parent inheritance structures. </div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">Have been following it since SE-0025, the aftermath, extensive experience using the modifiers in framework code I write and reading all related threads on SE.</div></blockquote><div class=""><br class=""></div><div class="">***</div><div class=""><br class=""></div>I propose instead that we revise to use Alternative #3, per Vladimir’s comment and revision.<div class=""><div class=""><br class=""></div><div class="">Revised version:</div><div class=""><br class=""></div><div class=""><b class="">“3. Revert <font face="Courier New" class="">private</font> to be file-based and introduce the scope-based access level under a new name (e.g.: <font face="Courier New" class="">scoped</font>, <font face="Courier New" class="">local</font>, etc), provided that the scope-based access modifier is not used at the top level of the file.” </b></div><div class="">(addendum via Vladimir’s revised comment)</div></div></blockquote><br><div>Yeah, <span style="background-color: rgba(255, 255, 255, 0);">within reason, </span>I couldn't care less how "private"/"fileprivate" are <i>spelled</i>. What I'm against is removing the <i>functionality</i> of the current "private" without simultaneously providing a semantically equivalent replacement.</div><div><br></div><div>- Dave Sweeris</div></body></html>