<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 22.04.2017 um 05:41 schrieb BJ Homer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">The "Access Control" section of the Swift 3 book says the following:</div><div class=""><div style="border: 0px; margin: 0px 0px 15px; outline: 0px; padding: 0px; vertical-align: baseline; line-height: 22.735998153686523px;" class=""><br class="webkit-block-placeholder"></div><blockquote type="cite" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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 class="">new default access level</b> for all members defined within the extension.</span></blockquote><div class=""><br class="webkit-block-placeholder"></div><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></div></div></blockquote><div>+1</div><div><br class=""></div><div>-Thorsten</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">-BJ</div></div><div class=""><br class="">On Apr 21, 2017, at 9:30 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class="">Never put stock in charlatans or compiler writers.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>