<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>My 2c on access control regarding extensions + global variables:</div><div><br></div><div>Another annoyance from SE-0025 was that "private" and "fileprivate" modifiers meant the same thing when dealing with extensions and global variables. Obviously this was for good reasons, but still seemed weird.</div><div><br></div><div>Regarding extensions now, I think it's nice that they actually <i>can</i> mean different things, so I definitely agree this is the right answer. I commonly mark extensions "private" simply to have the members inside default to that access level, rather than write "private" for each one. Now, should I have a collection of members that should be fileprivate, I can use a fileprivate extension for the same thing.</div><div><br></div><div>Regarding global variables, however, I actually thing the current behavior should remain. A truly private global variable makes no sense, and so declaring fileprivate vs private should continue to have the same behavior. While a very logical argument could be made that we should just enforce "fileprivate" for such instances, I personally think this runs counter to progressive disclosure. A programmer should only have to learn about fileprivate when trying to share internals of a type with another type, and not when simply declaring a global variable.</div><div><br></div><div>Playing devil's advocate, however, this might be a good thing. Now, when the programmer tries to declare a private global variable, they'll learn about the "fileprivate" modifier, and from that they'll learn what that does. So this would actually be a way of informing the programmer about fileprivate in the first place.</div><div><br></div><div>Again, I think keeping private/fileprivate as functionally equivalent for global variables is "easiest", and it's what my vote is for. Additionally, as weird as it might be to have two access control levels that "do the same thing" in this case, I think it makes more sense than <i>being unable to use "private" at all.</i> But since there are valid arguments to enforce fileprivate, I won't argue too much :-) I strongly believe access control on extensions should remain, however, and that private/fileprivate should have different results.</div><div><br></div><div>(Obviously, this doesn't affect public/internal modifiers)</div><div><br></div><div><br>On Apr 22, 2017, at 2:55 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sat, Apr 22, 2017 at 4:05 PM, Jose Cheyo Jimenez <span dir="ltr"><<a href="mailto:cheyo@masters3d.com" target="_blank">cheyo@masters3d.com</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"><div><div class="h5"><div></div><div><br></div><div><br>On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">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><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_7569026528926394336m_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_7569026528926394336m_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_7569026528926394336m_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_7569026528926394336m_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_7569026528926394336m_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></div><div>Properties in extensions? AKA partials ? I was thinking disallow only when properties are introduced in the extension not in general. </div></div></blockquote></div><br></div><div class="gmail_extra">No, disallowing access modifiers on extensions.</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>