<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>This type-and-file-based proposal addresses most of the *pragmatic* issues people run into when writing Swift, but I agree with other comments that it's a difficult mental model.</div><div><br></div><div>It sounds like most everyone likes the idea of renaming "private" -> "scoped" and "fileprivate" -> "private", but the code churn is considered too large for Swift 4. What about the following alternative, which is similar to SE-0159 but avoids the code churn:</div><div><br></div><div>- Revert the meaning of "private" to the Swift 2 meaning, as in SE-0159.</div><div>- Make "fileprivate" an alias for "private", as in SE-0159</div><div>- Migrator converts "fileprivate" -> "private", as in SE-0159</div><div>- Introduce "scoped", but perform no automatic migration for it.</div><div><br></div><div>The discussion around SE-0159 has shown that there are indeed important use cases for scoped access control. However, most instances of "private" in the wild are probably just due to its position as a "soft default", and don't need any migration. Developers who are relying on scoped access control are likely to be aware of locations where it is important, and could manually rewrite "private" to "scoped" for those sites. <span style="background-color: rgba(255, 255, 255, 0);">(For users who want to perform a full migration of "private" -> "scoped", perhaps a manual migration script could be provided.)</span></div><div><br></div><div>It's somewhat unfortunate to require manual migration to "scoped" for code that cares about scoped access, but I suggest that those use cases are rare and the developers are generally aware of such cases. This proposal prefers to limit the code churn instead, while getting rid of the "fileprivate" wart on the language. Most users would be able to migrate to Swift 4 with only the amount of migration already proposed in SE-0159.</div><div><br><div>-BJ</div></div><div><br></div><div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 3, 2017, at 8:34 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></div></div></body></html>