<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div>The "Access Control" 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 "private extension" in Swift 3 was a deviation from that model, justified because "private" 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 "private" in Swift 3 and the documentation quoted above, it seems unlikely that a developer would intentionally use "private extension" to mean "please make all this stuff visible to the entire file"—it would have worked, but it seems an odd way to write it. If that were the intention, I think "fileprivate extension" 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 "private extension" 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></div></div>
</div></blockquote><br><div>Properties in extensions? AKA partials ? I was thinking disallow only when properties are introduced in the extension not in general. </div></body></html>