<div dir="ltr">On Thu, Apr 20, 2017 at 6:31 PM, Douglas Gregor <span dir="ltr">&lt;<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>&gt;</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 style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Apr 20, 2017, at 3:39 PM, John McCall &lt;<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>&gt; wrote:</div><br class="m_1140068380170814046m_-5395754921401436152Apple-interchange-newline"><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"><blockquote type="cite"><div>On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><div><div dir="ltr">On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor<span class="m_1140068380170814046m_-5395754921401436152Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>&gt;</span><span class="m_1140068380170814046m_-5395754921401436152Apple-converted-space"> </span>wro<wbr>te:<br><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 style="word-wrap:break-word"><br><div><span><br><blockquote type="cite"><div>On Apr 20, 2017, at 11:33 AM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt; wrote:</div><br class="m_1140068380170814046m_-5395754921401436152m_-3425067472639878749Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_1140068380170814046m_-5395754921401436152m_-3425067472639878749Apple-interchange-newline"><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">This makes the private/fileprivate distinction meaningful for extensions. I think also bans the use of &quot;private&quot; 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><div>Wait, hang on, then people have to write &#39;fileprivate&#39; instead of &#39;private&#39; for top-level typealiases (and functions?).<span class="m_1140068380170814046m_-5395754921401436152Apple-converted-space"> </span></div></div></div></blockquote><div><br></div></span><div>That seems like the correct behavior; private is about members with SE-0169. What do you think?</div></div></div></blockquote><div><br></div><div>...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&#39;s no need for `private typealias` at the global level to be prohibited.</div></div></div></div></div></blockquote><div><br></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></div></span><div>So you’re okay with:</div><div><br></div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>private extension X {</div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>  func foo() { }</div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>}</div><div><br></div><div>being equivalent to</div><div><br></div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>extension X {</div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>  fileprivate func foo() { }</div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>}</div><div><br></div><div>rather than</div><div><br></div><div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>extension X {</div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>  private func foo() { }</div><div><span class="m_1140068380170814046m_-5395754921401436152Apple-tab-span" style="white-space:pre-wrap">        </span>}</div><div><br></div></div><div>?</div><div><br></div><div>That seems unintuitive at best.</div></div></blockquote><div><br></div><div>Agree, but the rules for access modifiers in front of extensions have always been different from those for everything else. Surely, we can rationalize extensions here as you suggest without having to prohibit private typealiases.</div><div> </div></div></div></div>