<div dir="ltr"><span><div>> Swift's access modifier control is about code unit access levels. This proposal breaks this conceptual model. Now instead of thinking of publicly exposed APIs, APIs using only within the context of the module, and APIs local to the file, I now need to parse semantic scopes to understand where a piece of code can be used.</div><div><br></div><div>> Basically Swift's model is:</div><div> - public exports</div><div> - internal exports</div><div> - no exports</div><div><br></div><div>> This proposal doesn't fit anywhere in that model.</div><div><br></div><div>This is one interoperation. Here is another that makes it fit perfectly well:</div><div><br></div><div>- public: exports symbol to all files</div><div>- internal: exports symbol to module files</div><div>- private: exports symbol to one file containing the scope</div><div>- scoped: no export</div><div><br></div><div>> Yes, this basically what private is other languages. However, traditionally "private scope" implementations have severe weaknesses in the ability to expose the implementation details only to helper code within the same file. Creating local re-invents part of that.<br></div><div><br></div><div>Yes, and "private" is great for that. We can have both. They serve different purposes.</div></span><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 29, 2016 at 12:31 PM David Owens II 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"><div style="word-wrap:break-word"><div><b>What is your evaluation of the proposal?<br></b></div><div><b><br></b></div></div><div style="word-wrap:break-word"><div>-1. I disagree with the starting motivation points, so it's hard to really see the value in the rest of the arguments.</div></div><div style="word-wrap:break-word"><div><b><br></b></div><div><b>Is the problem being addressed significant enough to warrant a change to Swift?<br></b></div><div><br></div></div><div style="word-wrap:break-word"><div>No.</div></div><div style="word-wrap:break-word"><div><b><br></b></div><div><b>Does this proposal fit well with the feel and direction of Swift?<br></b></div><div><b><br></b></div></div><div style="word-wrap:break-word"><div>No. Swift's access modifier control is about code unit access levels. This proposal breaks this conceptual model. Now instead of thinking of publicly exposed APIs, APIs using only within the context of the module, and APIs local to the file, I now need to parse semantic scopes to understand where a piece of code can be used.</div><div><br></div><div>Basically Swift's model is:</div><div> - public exports</div><div> - internal exports</div><div> - no exports</div><div><br></div><div>This proposal doesn't fit anywhere in that model.</div></div><div style="word-wrap:break-word"><div><b><br></b></div><div><b>If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></b></div><div><br></div></div><div style="word-wrap:break-word"><div>Yes, this basically what private is other languages. However, traditionally "private scope" implementations have severe weaknesses in the ability to expose the implementation details only to helper code within the same file. Creating local re-invents part of that. </div></div><div style="word-wrap:break-word"><div><br></div><div><b>How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b></div><div><b><br></b></div></div><div style="word-wrap:break-word"><div>I've read the review and followed much of the conversation, including participating in the previous thread on this topic.</div></div>_______________________________________________<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>