<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 21, 2017, at 8:41 PM, BJ Homer via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>The "Access Control" section of the Swift 3 book says the following:</div><div><p class="para" 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="code-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="para" 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="para" 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="para" 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>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><div><br></div><div><br><blockquote type="cite"><div><div><br>On Apr 21, 2017, at 9:30 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 20, 2017, at 7:53 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; 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" class=""><div class="">On Apr 20, 2017, at 7:31 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Apr 20, 2017, at 3:39 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; 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;"><blockquote type="cite" class=""><div class="">On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="">On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dgregor@apple.com" target="_blank" class="">dgregor@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 20, 2017, at 11:33 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>> wrote:</div><br class="m_-3425067472639878749Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3425067472639878749Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; 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;">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></blockquote></div><br class=""><div class="">Wait, hang on, then people have to write 'fileprivate' instead of 'private' for top-level typealiases (and functions?).<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That seems like the correct behavior; private is about members with SE-0169. What do you think?</div></div></div></blockquote><div class=""><br class=""></div><div class="">...that seems suboptimal, given that the goal has been to make it possible for people to use `private` more and not less frequently. IMO, there's no need for `private typealias` at the global level to be prohibited.</div></div></div></div></div></blockquote><div class=""><br class=""></div>Yeah, I see no reason for this to change the behavior of private extensions to be more restrictive than before.</div></div></blockquote><br class=""></div><div class="">So you’re okay with:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>private extension X {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span> func foo() { }</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div class=""><br class=""></div><div class="">being equivalent to</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>extension X {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span> fileprivate func foo() { }</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div class=""><br class=""></div><div class="">rather than</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>extension X {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span> private func foo() { }</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div class=""><br class=""></div></div><div class="">?</div><div class=""><br class=""></div><div class="">That seems unintuitive at best.</div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; 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="">Perhaps, but it's existing unintuitive behavior. Are you suggesting that SE-0169 rationalizes changing it because (1) it's likely that a private extension is just meant for the use of other extensions of that type in the current file and (2) SE-0169 already allows such uses and so justifies the stricter rule? That is an interesting theory, but I'm not sure I believe (1). </div></div></blockquote><div><br class=""></div><div>I’m saying (2), and I suspect (1) is most often the case… but I agree that we’re likely to end up breaking code here.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; 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="">More importantly, though, SE-0169 didn't actually propose changing this behavior, and it's a very substantial shift in behavior, and we haven't actually discussed or gathered any community feedback about it, so I'm really struggling to see why it wouldn't need to be a separate evolution proposal. </div></div></blockquote><div><br class=""></div><div>I was interpreting SE-0169 to mean this, but you are correct: SE-0169 doesn’t spell out a change here.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; 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="">And that would be difficult because, as a wise man once said to me, 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></blockquote><br class=""></div><div>Never put stock in charlatans or compiler writers.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></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></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></div></div></body></html>