<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 23:34, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" 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 Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">[Resending with fewer recipients]<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 29, 2016 at 8:55 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=""><div class="">Updated in <a href="https://github.com/apple/swift-evolution/pull/396" target="_blank" class="">https://github.com/apple/swift-evolution/pull/396</a>. Thanks again, everyone!</div></div></blockquote><div class=""> </div><span style="font-size:12.8px" class="">As usual, a thoughtful result from the core team. Curious, though, where does the following statement come into play?</span><br class=""><span style="font-size:12.8px" class=""><br class=""></span><div style="word-wrap:break-word" class=""><span class=""><font color="#888888" class=""><div style="color:rgb(34,34,34);font-size:12.8px" class="">"The access level of a conformance concerning a `private` type or protocol is considered to be `fileprivate` rather than `private`."</div></font></span></div></div></div></div></div></blockquote><div class=""><br class=""></div>I think the internal representation may be leaking out. I believe this is the right basic approach for formalizing the language rules here:</div><div class=""><br class=""></div><div class="">1. A scope S has access to a declaration D if S has access to the scope S_D in which D is declared and:</div><div class=""> - if D is explicitly declared 'private', S is equal to S_D or lexically nested within S_D,</div><div class=""> - if D is explicitly declared 'fileprivate', S appears within the same file as S_D,</div><div class=""> - if D is explicitly declared 'internal', S appears within the same module as S_D, or</div><div class=""> - if D lacks an explicit access specifier, S appears within the same module as S_D or S_D is a public extension (*).</div><div class="">(*) I believe this special case rule about public extensions is correct for the current model. I'm not sure it's a good idea, though.</div><div class=""><br class=""></div><div class="">2. A scope S has access to a scope T if:</div><div class=""> - S is equal to T or is lexically nested within it,</div><div class=""> - T is a declaration D and S has access to D, or</div><div class=""> - T is a file scope.</div></div></div></blockquote><div><br class=""></div><div>…and S is in the same file?</div><div><br class=""></div><div>(We never formalized “scope”. Mostly it’s “curly braces, ish”. Not quite 1-1 with “DeclContext”.)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">3. A declaration D shall not use in its signature any declaration D_sig for which there potentially exists a scope S such that S has access to D but not D_sig. The signature of a declaration includes:</div><div class=""> - the explicit type of a function, initializer, variable, or constant declaration; or its inferred type (fully "desugared", e.g. ignoring all type aliases) if an explicit type is not given</div><div class=""> - the underlying type of a typealias or associatedtype declaration</div><div class=""> - the superclass type of a class declaration</div><div class=""><div class=""> - the conformance list of a class, struct, enum, protocol, or extension declaration</div><div class=""> - the generic parameters and constraints of a generic declaration</div><div class=""></div><div class=""> - etc.</div><div class=""><br class=""></div><div class="">Formally, there's no need to decide the "real" or "effective" access modifier for a declaration. Conveniently (and not coincidentally), these rules do end up being equivalent to computing an effective access level by just merging information down from the lexical container, but that's emergent, not fundamental, so don't put too much energy into whether the emergent access level "makes sense" as a description.</div></div></div></div></blockquote><br class=""></div><div>Right. “Effective access” is a query in the compiler to determine the AST’s notion of symbol visibility; it’s not a term we want to use in the language spec.</div><div><br class=""></div><div>These rules seem correct, but they’re not complete—they’re missing the restriction on witnesses for protocol requirements.</div><div><br class=""></div><div>To Xiaodi’s original question, the notion of an access level for conformances is groundwork for a world where you can have conformances with less access than the type or protocol. We’re not in such a world, though, so I should just remove it. (I was reminded of it when rereading the original Access Control writeup, <a href="https://github.com/apple/swift/blob/master/docs/AccessControl.rst" class="">https://github.com/apple/swift/blob/master/docs/AccessControl.rst</a>.)</div><div><br class=""></div><div>Jordan</div></body></html>