<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div><span style="background-color: rgba(255, 255, 255, 0);">While I am disappointed that SE-0159 got rejected, this alternative would resolve most issues I have with the current model. It would allow us to once again use private as a good default.</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);">I really care about this topic so I volunteer for writing the proposal if nobody feels strongly about it.</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);">Btw, I know what I'm going to propose is a bit crazy, but how about making private visible to extensions even outside the file but in the same module?</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);">David.</span></div></div><div><br>On 3 Apr 2017, at 20:34, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Hello Swift Community,<div class=""><br class=""></div><div class="">In rejecting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" class="">SE-0159</a>, the core team described a potential direction we would like to investigate for “private” access control that admits a limited form of type-based access control within files. The core team is seeking some discussion here and a motivated volunteer to put together a proposal along these lines for review in the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s sure this is the right direction to go… but it appears promising and we would *love* to be able to settle the access-control issue.</div><div class=""><br class=""></div><div class="">The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:</div><div class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* An extension of “X” in the same file</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* The definition of “X”, if it occurs in the same file</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* A nested type (or extension thereof) of one of the above that occurs in the same file</div><div class=""><br class=""></div><div class="">This design has a number of apparent benefits:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ “private” becomes the right default for “less than whole module” visibility, and aligns well with Swift coding style that divides a type’s definition into a number of extensions.</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ “fileprivate” remains for existing use cases, but now it’s use it more rare, which has several advantages:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ It fits well with the "progressive disclosure” philosophy behind Swift: you can use public/internal/private for a while before encountering and having to learn about “fileprivate” (note: we thought this was going to be true of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" class="">SE-0025</a>, but we were clearly wrong)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ When “fileprivate” occurs, it means there’s some interesting coupling between different types in the same file. That makes fileprivate a useful alert to the reader rather than, potentially, something that we routinely use and overlook so that we can separate implementations into extensions.</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ “private” is more closely aligned with other programming languages that use type-based access control, which can help programmers just coming to Swift. When they reach for “private”, they’re likely to get something similar to what they expect—with a little Swift twist due to Swift’s heavy use of extensions.</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ Loosening the access restrictions on “private” is unlikely to break existing code.</div><div class=""><br class=""></div><div class="">There are likely some drawbacks:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Developers using patterns that depend on the existing lexically-scoped access control of “private” may find this new interpretation of “private” to be insufficiently strict</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Swift’s access control would go from “entirely lexical” to “partly lexical and partly type-based”, which can be viewed as being more complicated</div><div class=""><br class=""></div></div><div class="">Thoughts? Volunteer?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>