<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><div><br><br>Sent from my iPhone</div>On Apr 18, 2017, at 6:58 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>Does the acceptance of SE-0169 imply any change to rules for `private extension` members, or does the core team intend such members to continue defaulting to fileprivate visibility?</div></div></blockquote><div><br></div>It does imply a change to "private extension" semantics: the members of such an extension would be "private", so they'd be visible to other extensions (and possibly the definition of) the extended type that occur in the same file. <div><br></div><div>This makes the private/fileprivate distinction meaningful for extensions. I think also bans the use of "private" at global scope for non-nominal types or extensions thereof. A clarifying update to the proposal is in order, so developers can better understand the semantics. </div><div><br></div><div>Hey, and this gives me another reason why</div><div><br></div><div> extension P where Self : Q { }</div><div><br></div><div>Might be a better spelling than</div><div><br></div><div> extension P & Q { }</div><div><br></div><div>Despite the latter being more obvious :)</div><div><br></div><div> - Doug</div><div><br></div><div><br></div><div><blockquote type="cite"><div><div><br></div><div><br><div class="gmail_quote"><div>On Mon, Apr 17, 2017 at 19:25 Douglas Gregor 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">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md</a><div><br></div><div>Hello Swift Community,</div><div><br></div><div>The review of SE-0169 "Improve Interaction Between `private` Declarations and Extensions” ran from April 6...11, 2017. The proposal is <b>accepted</b>.</div><div><br></div><div>This topic has been highly controversial for a long time, both during Swift 3’s development (when <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" target="_blank">SE-0025</a> was introduced) and during Swift 4 (including <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" target="_blank">SE-0159</a> and <a href="https://github.com/apple/swift-evolution/pull/680" target="_blank">other</a> <a href="https://github.com/apple/swift-evolution/pull/681" target="_blank">proposals</a>). There is no solution that will make everyone happy: maintaining the status quo makes “fileprivate” too common and therefore not meaningful when it occurs in source; removing or diluting scope-level access control (as in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" target="_blank">SE-0159</a> and this proposal) takes away a tool that is in use by Swift developers; and adding more levels of access control complicates the language.</div><div><br></div><div>The core team feels that this proposal makes <font face="Menlo">private</font> access align more closely with the goals of the language:</div><div><br></div><div><ul class="m_-259153892566799306MailOutline"><li>It supports the notion that extensions are a code-organization tool: one should be able to break up a type’s definition into several extensions to improve the clarity of that code, without having to open up access or otherwise view the members in different extensions as completely-distinct entities. The core team expects future language evolution to reinforce the notion that extensions are more of a code organization tool than distinct entities, e.g., allowing stored properties to be introduced in an extension.</li><li>It makes <font face="Menlo">private</font> more usable as the default sub-<font face="Menlo">internal</font> access level, which supports progressive disclosure of the access control system and better matches with programmer’s expectations about what <font face="Menlo">private</font> access means.</li><li>It makes <font face="Menlo">fileprivate</font> more meaningful, because it is only needed for those cases where one is reaching across types (or among types and globals) within a file. It will also become more rare, which matches well with its longer, descriptive name.</li></ul><div><br></div></div><div>The proposal’s acceptance includes one modification: extensions of a given type that reside in a single file that is different from the file that defines the type itself will have access to the <font face="Menlo">private</font> members of all other extensions in that file. For example:</div><div><br></div><div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;color:rgb(36,41,46)"><span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-259153892566799306pl-c" style="box-sizing:border-box">//</span> FileA.swift</span>
<span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span><span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">struct</span> <span class="m_-259153892566799306pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">A</span> {
<span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">private</span> <span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">var</span> aMember <span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> <span class="m_-259153892566799306pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Int</span>
}
<span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-259153892566799306pl-c" style="box-sizing:border-box">//</span> FileB.swift</span>
<span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span><span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">extension</span> <span class="m_-259153892566799306pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">A</span> {
<span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">private</span> <span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">func</span> <span class="m_-259153892566799306pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">foo</span>() {
<span class="m_-259153892566799306pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">bar</span>() <span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-259153892566799306pl-c" style="box-sizing:border-box">//</span> ok, foo() does have access to bar()</span>
<span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span> }
}
<span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">extension</span> <span class="m_-259153892566799306pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">A</span> {
<span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">private</span> <span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">func</span> <span class="m_-259153892566799306pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">bar</span>() {
aMember <span class="m_-259153892566799306pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">=</span> <span class="m_-259153892566799306pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">42</span> <span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-259153892566799306pl-c" style="box-sizing:border-box">//</span> not ok, private members may not be accessed outside their file.</span>
<span class="m_-259153892566799306pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span> }
}</pre><div><br></div></div><div>The proposal has already been updated to reflect this change, which better reflects the notion that extensions are a code-organization tool.</div><div><br></div><div>The core team considers the access-control matter closed for Swift 4 and will not be reviewing any further proposals in this area.</div><div><br></div><div><span class="m_-259153892566799306Apple-tab-span" style="white-space:pre-wrap"> </span>- Doug</div><div><span class="m_-259153892566799306Apple-tab-span" style="white-space:pre-wrap"> </span>Review Manager</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>
</div></blockquote></div></body></html>