<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="">On Jun 29, 2016, at 17:04, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">[Resending with fewer recipients due to list rules.]<div class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 29, 2016 at 6:51 PM, Jordan Rose <span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span> wrote:<br class=""><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" class="">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" class="">amendment</a> tonight. But in short:<div class=""><br class=""></div><div class="">- The default access level will be 'internal' everywhere*. The compiler will not warn if the access-as-written is broader than necessary. <i class="">Motivation: it should be possible to design a type's API as if it had more access than it currently does.</i></div><div class=""><br class=""></div><div class="">* except in extensions, see below</div><div class=""><br class=""></div><div class="">- The complicated "rule 2" from the amendment stands, but possibly in a form that isn't specific to 'fileprivate':</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><blockquote type="cite" class="">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 class=""><br class=""></div><div class="">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's still safe. That would look like this:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><blockquote type="cite" class="">A member may not have a type that references any declarations that aren't accessible wherever the member is accessible.</blockquote></blockquote><br class=""><div class="">I'm concerned about that being <i class="">too</i> permissive, though. I still want this to be considered an error:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">fileprivate struct Foo {</div><div class=""> fileprivate typealias Bar = Int</div><div class=""> internal func baz() -> Bar { … }</div><div class="">}</div></blockquote></div></blockquote><div class=""> </div><div class=""><div style="font-size:12.8px" class="">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 class=""><br class=""></div><div class="">```</div><div class="">fileprivate struct Foo {</div><div class=""> fileprivate typealias Bar = Int</div></span><div style="font-size:12.8px" class=""> func baz() -> Bar { ... }</div><div style="font-size:12.8px" class="">}</div><div style="font-size:12.8px" class="">```</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">That would, I think, be surprising. Thus, I'd recommend the broader rule. What makes you conclude that it's too permissive?</div></div><div class=""> </div></div></div></div></div></div></blockquote><br class=""><div>Ah, right, that would break backwards-compatibility. The broader rule it is!</div><div><br class=""></div><div>Thanks, Xiaodi.</div><div>Jordan</div><div class=""><br class=""></div></div></body></html>