<div dir="ltr">On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div></div><div><br></div><div><br>On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div>The &quot;Access Control&quot; section of the Swift 3 book says the following:</div><div><p class="m_6012389728079243519para" style="border:0px;margin:0px 0px 15px;outline:0px;padding:0px;vertical-align:baseline;line-height:22.735998153686523px"></p><blockquote type="cite"><span style="background-color:rgba(255,255,255,0)">You can mark an extension with an explicit access-level modifier (for example, <code class="m_6012389728079243519code-voice" style="border:0px;margin:0px;outline:0px;padding:0px;vertical-align:baseline;word-break:break-all;word-wrap:break-word">private extension</code>) to set a <b>new default access level</b> for all members defined within the extension.</span></blockquote><p></p><p class="m_6012389728079243519para" style="border:0px;margin:0px 0px 15px;outline:0px;padding:0px;vertical-align:baseline;line-height:22.735998153686523px">The behavior of &quot;private extension&quot; in Swift 3 was a deviation from that model, justified because &quot;private&quot; as a default would have meant that nothing in the extension could ever be called. But it was still contrary to the model suggested by the Swift documentation. </p><p class="m_6012389728079243519para" style="border:0px;margin:0px 0px 15px;outline:0px;padding:0px;vertical-align:baseline;line-height:22.735998153686523px">Given the highly restrictive behavior of &quot;private&quot; in Swift 3 and the documentation quoted above, it seems unlikely that a developer would intentionally use &quot;private extension&quot; to mean &quot;please make all this stuff visible to the entire file&quot;—it would have worked, but it seems an odd way to write it. If that were the intention, I think &quot;fileprivate extension&quot; would have been more likely.</p><p class="m_6012389728079243519para" style="border:0px;margin:0px 0px 15px;outline:0px;padding:0px;vertical-align:baseline;line-height:22.735998153686523px">I think the change to the behavior of &quot;private extension&quot; is in line with the model proposed by SE-0169, in line with the documented behavior of access control on extensions, and in line with user expectations.</p><div>-BJ</div></div></div></blockquote><div><br></div></span>I understand your point. Another aspect of SE-0169 is that fileprivate should be more rare and thus meaningful when used. The current behavior stays true to the goal of making fileprivate rare. <div><br></div><div>A top level private scope is effectively fileprivate so it is not totally weird for the extension members to inherit the top level private scope. </div><div><br></div><div>When extensions gain the ability to contain properties, we should not allow the access level modifiers to the extensions in the same way protocol extensions prohibit its use. </div></div></blockquote><div><br></div><div>That idea would be my preference too, but it has been already written up as a proposal, considered, and rejected.</div><div><br></div><div><br></div></div></div></div>