<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=""><div class="">-1 to the new proposal. We should avoid a hybrid “private” which is both lexically scoped *and* “something completely different”. Confusing.</div><div class=""><br class=""></div><div class="">+1 to BJ Homer’s opinion, with the caveat that we at least provide an option (checkbox?) in the Xcode migrator to migrate “private” to “scoped” so the programmer can make an informed choice and not lose their original intent.</div><div class=""><br class=""></div><div class="">As an aside, have we considered if “scoped" is too technical of a term? I’m leaning toward “local” is being more idiosyncratic and Swifty.</div><div class=""><br class=""></div><div class="">- David James</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 4, 2017, at 12:35 PM, Vladimir.S via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">On 04.04.2017 5:03, BJ Homer via swift-evolution wrote:</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: CourierNewPS-BoldMT; 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="">This type-and-file-based proposal addresses most of the *pragmatic* issues<br class="">people run into when writing Swift, but I agree with other comments that<br class="">it's a difficult mental model.<br class=""><br class="">It sounds like most everyone likes the idea of renaming "private" -&gt;<br class="">"scoped" and "fileprivate" -&gt; "private", but the code churn is considered<br class="">too large for Swift 4. What about the following alternative, which is<br class="">similar to SE-0159 but avoids the code churn:<br class=""><br class="">- Revert the meaning of "private" to the Swift 2 meaning, as in SE-0159.<br class="">- Make "fileprivate" an alias for "private", as in SE-0159<br class="">- Migrator converts "fileprivate" -&gt; "private", as in SE-0159<br class="">- Introduce "scoped", but perform no automatic migration for it.<br class=""></blockquote><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">FWIW Currently I believe this is the best alternative/compromise we can have. I think anyone who defer the current scoped 'private' is OK to manually change it to 'scoped' in new version of Swift.</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">And those who support SE-0159 will have Swift 2.0 'private'. As for fileprivate probably it should be marked as deprecated so we can later remove it from language.</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Actually I'm very surprised :-( of core team decision and ultimate reaction on community's loud request to rename fileprivate-&gt;private and current private-&gt;scoped to achieve the both targets(to have Swift 2 'private' instead of 'fileprivate' and keep the usefull current 'private' access level). In addition it was said that it is the last chance to change anything in access modifiers. IMO this BJ Homer's solution/compromise is the way we *should* go given that this is *the last chance* to improve the situation with access modifiers.</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">As was said by core team, there will be no *any* reconsideration on access levels/keywords after this, even for submodules etc. And core team even did not discussed a lot features like submodules in the light of access modifiers(they said this).</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I want to ask/recommend anyone who want to improve the situation with access modifiers - reply to BJ Homer's message with support for it, so core team can see the consolidated opinion they can take into account.</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: CourierNewPS-BoldMT; 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=""><br class="">The discussion around SE-0159 has shown that there are indeed important use<br class="">cases for scoped access control. However, most instances of "private" in<br class="">the wild are probably just due to its position as a "soft default", and<br class="">don't need any migration. Developers who are relying on scoped access<br class="">control are likely to be aware of locations where it is important, and<br class="">could manually rewrite "private" to "scoped" for those sites. (For users<br class="">who want to perform a full migration of "private" -&gt; "scoped", perhaps a<br class="">manual migration script could be provided.)<br class=""><br class="">It's somewhat unfortunate to require manual migration to "scoped" for code<br class="">that cares about scoped access, but I suggest that those use cases are rare<br class="">and the developers are generally aware of such cases. This proposal prefers<br class="">to limit the code churn instead, while getting rid of the "fileprivate"<br class="">wart on the language. Most users would be able to migrate to Swift 4 with<br class="">only the amount of migration already proposed in SE-0159.<br class=""><br class="">-BJ<br class=""><br class=""><blockquote type="cite" class="">On Apr 3, 2017, at 8:34 PM, Douglas Gregor via swift-evolution<br class="">&lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space">&nbsp;</span>&lt;<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>&gt;&gt; wrote:<br class=""><br class="">Hello Swift Community,<br class=""><br class="">In rejecting SE-0159<br class="">&lt;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md</a>&gt;,<br class="">the core team described a potential direction we would like to<br class="">investigate for “private” access control that admits a limited form of<br class="">type-based access control within files. The core team is seeking some<br class="">discussion here and a motivated volunteer to put together a proposal<br class="">along these lines for review in the Swift 4 time-frame (i.e., very soon).<br class="">To be clear, the core team it’s sure this is the right direction to go…<br class="">but it appears promising and we would *love* to be able to settle the<br class="">access-control issue.<br class=""><br class="">The design, specifically, is that a “private” member declared within a<br class="">type “X” or an extension thereof would be accessible from:<br class=""><br class="">* An extension of “X” in the same file<br class="">* The definition of “X”, if it occurs in the same file<br class="">* A nested type (or extension thereof) of one of the above that occurs in<br class="">the same file<br class=""><br class="">This design has a number of apparent benefits:<br class="">+ “private” becomes the right default for “less than whole module”<br class="">visibility, and aligns well with Swift coding style that divides a type’s<br class="">definition into a number of extensions.<br class="">+ “fileprivate” remains for existing use cases, but now it’s use it more<br class="">rare, which has several advantages:<br class="">+ It fits well with the "progressive disclosure” philosophy behind Swift:<br class="">you can use public/internal/private for a while before encountering and<br class="">having to learn about “fileprivate” &nbsp;&nbsp;(note: we thought this was going to<br class="">be true of SE-0025<br class="">&lt;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md</a>&gt;,<br class="">but we were clearly wrong)<br class="">+ When “fileprivate” occurs, it means there’s some interesting coupling<br class="">between different types in the same file. That makes fileprivate a useful<br class="">alert to the reader rather than, potentially, something that we routinely<br class="">use and overlook so that we can separate implementations into extensions.<br class="">+ “private” is more closely aligned with other programming languages that<br class="">use type-based access control, which can help programmers just coming to<br class="">Swift. When they reach for “private”, they’re likely to get something<br class="">similar to what they expect—with a little Swift twist due to Swift’s<br class="">heavy use of extensions.<br class="">+ Loosening the access restrictions on “private” is unlikely to break<br class="">existing code.<br class=""><br class="">There are likely some drawbacks:<br class="">- Developers using patterns that depend on the existing lexically-scoped<br class="">access control of “private” may find this new interpretation of “private”<br class="">to be insufficiently strict<br class="">- Swift’s access control would go from “entirely lexical” to “partly<br class="">lexical and partly type-based”, which can be viewed as being more complicated<br class=""><br class="">Thoughts? Volunteer?<br class=""><br class="">- Doug<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><span class="Apple-converted-space">&nbsp;</span>&lt;<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>&gt;<br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""><br class="">_______________________________________________<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=""><br class=""></blockquote><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: CourierNewPS-BoldMT; 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: CourierNewPS-BoldMT; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: CourierNewPS-BoldMT; 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=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Verdana;  font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Verdana; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Verdana; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Verdana; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">David James</div></div></span></div></span></div></span></div></div>
</div>
<br class=""></div></body></html>