<div dir="ltr">[Resending with fewer recipients due to list rules.]<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 29, 2016 at 6:51 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">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></blockquote><div> </div><div><div style="font-size:12.8px">If the default access level is internal everywhere, then the example above being an error would mean that this also becomes an error:</div><span class="im" style="font-size:12.8px"><div><br></div><div>```</div><div>fileprivate struct Foo {</div><div>  fileprivate typealias Bar = Int</div></span><div style="font-size:12.8px">  func baz() -&gt; Bar { ... }</div><div style="font-size:12.8px">}</div><div style="font-size:12.8px">```</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">That would, I think, be surprising. Thus, I&#39;d recommend the broader rule. What makes you conclude that it&#39;s too permissive?</div></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"><div></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><span class=""><font color="#888888"><div><br></div></font></span><div><span class=""><font color="#888888">Jordan<br></font></span><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></blockquote></div><br></div></div></div>