<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=""><div><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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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>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). 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. 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><br class=""></div><div>John.</div><br class=""></body></html>