<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 7, 2017, at 9:48 AM, David Hart 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=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 7 Apr 2017, at 15:41, BJ Homer 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=""><div dir="auto" class=""><div class=""><div class="">-0.5</div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">SE-0159 was rejected because it was determined that some developers are actively using strongly-scoped access control. This proposal removes that strong scoping, so I do not see how we can reasonably reject that proposal but accept this one.</span></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t know what you mean by<span class="Apple-converted-space"> </span><b class="">strong</b><span class="Apple-converted-space"> </span>in <b class="">strong</b>-scoped access, but your statement seems false. It does not remove the scoped access control, it only relaxes it in extensions to types in the same file.</div></div></div></blockquote><div><br class=""></div><div>This relaxation makes the resulting scoping decidedly less strong. It is no longer lexical and would require a user to consider all code in the file. This means the strong, compiler-verified guarantee of scoped access that a small number of lines can see a member is eliminated. The whole file must be considered. As others have noted, that defeats the primary purpose of having scoped access control in the first place.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">The entire reason we're having this discussion is that "fileprivate" is such an awkward term for something that's so common in the language. I think the main thing we need to fix is the naming of that keyword.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">The name of fileprivate is not reason for this proposal. fileprivate has an awkward name precisely because it was planned for it to be used less often. This proposal’s goal is to make private more attractive to fulfil that original goal. fileprivate’s awkwardness is good, because it attracts attention to it when it is used.</div></div></div></blockquote><div><br class=""></div><div>Your previous proposal eliminated this distinction entirely and if I understand correctly you still believe that is the best solution. With that in mind, do you really consider it important to call special attention to same-file, cross-type members? If we’re going to have a distinction in the language, do you really consider this a more important and useful distinction than the distinction supporting the use cases for scoped access? If the answer to either of those questions is no I find it hard to understand how this issue is not simply about having the ability to say `private` most of the time (which is a naming issue not a semantics issue).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">I continue to believe that the best solution is to revert "private" to mean file scope as in Swift 2, and introduce a new "scoped" keyword for those developers who are specifically desiring the scoped functionality. This was rejected during the discussion because the migration would be too disruptive, but it is only disruptive if the migrator rewrites "private"->"scoped". I assert that most developers would not *want* that migration to happen; most developers use "private" because they want the default less-than-internal access control. The few developers who are using specifically scoped control can modify their code manually. Under this model, scoped access control is still available for those who need it, and most users can once again use "private" in cases where it is the natural default. </span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">This proposal proposes that "fileprivate" would become a marker to call out cases where exceptional across-type access is happening. In practice, I don't believe that will happen, simply because there are many existing cases of "fileprivate" out there, and this proposal does not suggest migrating them.</span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class="">I also disagree that it's useful to call out "fileprivate" as an exceptional case. It's slightly useful, I'll acknowledge, but it would be *more* useful to call out the exceptional cases where scope-only control is being used.</div><div class=""><br class=""></div><div class="">So I disagree with the proposal. But I give it only -0.5 because even with all of that, this is a better definition for "private" than the current one.</div><div class=""><br class=""></div>-BJ</div><div class=""><br class="">On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div 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></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>