<div dir="ltr">[Resending with fewer recipients]<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 29, 2016 at 8:55 PM, Jordan Rose <span dir="ltr">&lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Updated in <a href="https://github.com/apple/swift-evolution/pull/396" target="_blank">https://github.com/apple/swift-evolution/pull/396</a>. Thanks again, everyone!</div></div></blockquote><div> </div><span style="font-size:12.8px">As usual, a thoughtful result from the core team. Curious, though, where does the following statement come into play?</span><br><span style="font-size:12.8px"><br></span><div style="word-wrap:break-word"><span class=""><font color="#888888"><div style="color:rgb(34,34,34);font-size:12.8px">&quot;The access level of a conformance concerning a `private` type or protocol is considered to be `fileprivate` rather than `private`.&quot;</div></font></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class=""><font color="#888888"><div>Jordan</div></font></span><div><div class="h5"><br><div><blockquote type="cite"><div>On Jun 29, 2016, at 16:51, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">I just attended a core team meeting where this whole thing was discussed, and will update our <a href="https://github.com/apple/swift-evolution/pull/383" target="_blank">amendment</a> tonight. But in short:<div><br></div><div>- The default access level will be &#39;internal&#39; everywhere*. The compiler will not warn if the access-as-written is broader than necessary. <i>Motivation: it should be possible to design a type&#39;s API as if it had more access than it currently does.</i></div><div><br></div><div>* except in extensions, see below</div><div><br></div><div>- The complicated &quot;rule 2&quot; from the amendment stands, but possibly in a form that isn&#39;t specific to &#39;fileprivate&#39;:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><blockquote type="cite">A non-private method, initializer, subscript, property, or typealias may still have a type that references `private` declarations if (1) the non-private declaration is a member of a private type, and (2) all referenced `private` declarations are defined within an enclosing lexical scope. That is, it is legal for a non-private member within a `private` type to have a type that is formally `private` if it would be legal for a `private` declaration in the parent scope to have that type.</blockquote></div></blockquote><div><br></div><div>As Xiaodi pointed out, this could be even broader, to say that an internal member may reference a fileprivate type if the member is itself defined within a fileprivate type, because it&#39;s still safe. That would look like this:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote type="cite">A member may not have a type that references any declarations that aren&#39;t accessible wherever the member is accessible.</blockquote></blockquote><br><div>I&#39;m concerned about that being <i>too</i> permissive, though. I still want this to be considered an error:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>fileprivate struct Foo {</div><div>  fileprivate typealias Bar = Int</div><div>  internal func baz() -&gt; Bar { … }</div><div>}</div></blockquote><div><br></div>- An access modifier on an extension has been ruled to indicate the desired <i>scope,</i> not the desired <i>access.</i> Therefore, members within a `private extension` will be `fileprivate`. (We&#39;re only really getting away with this because we don&#39;t allow extensions anywhere but at the top level, though if we had nested extensions we&#39;d probably consider them scoped anyway.)<div><br></div><div>- We are not looking at renaming either &#39;fileprivate&#39; or &#39;private&#39; for Swift 3.<br><div><br></div><div>- All this has been ruled not to need a formal review.</div><div><br></div><div>Thanks everyone for getting us to this point. It&#39;s definitely different from what I would have come up with on my own or just collaborating with Robert, so you can all count yourselves as contributors to this one. :-)</div><div><br></div><div>Jordan<br><br><div>P.S. If you see further issues here I&#39;d still like to hear them; if you&#39;re unclear on any points after I&#39;ve updated the <a href="https://github.com/apple/swift-evolution/pull/383" target="_blank">pull request</a>, I&#39;m happy to go over them again.</div></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>