[swift-evolution] [Discussion] A Problem With SE-0025?

[John McCall]

> On Jun 30, 2016, at 9:19 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>> On Jun 29, 2016, at 23:34, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> On Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> [Resending with fewer recipients]
>>> 
>>> On Wed, Jun 29, 2016 at 8:55 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>> Updated in https://github.com/apple/swift-evolution/pull/396 <https://github.com/apple/swift-evolution/pull/396>. Thanks again, everyone!
>>>  
>>> As usual, a thoughtful result from the core team. Curious, though, where does the following statement come into play?
>>> 
>>> "The access level of a conformance concerning a `private` type or protocol is considered to be `fileprivate` rather than `private`."
>> 
>> I think the internal representation may be leaking out.  I believe this is the right basic approach for formalizing the language rules here:
>> 
>> 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:
>>   - if D is explicitly declared 'private', S is equal to S_D or lexically nested within S_D,
>>   - if D is explicitly declared 'fileprivate', S appears within the same file as S_D,
>>   - if D is explicitly declared 'internal', S appears within the same module as S_D, or
>>   - if D lacks an explicit access specifier, S appears within the same module as S_D or S_D is a public extension (*).
>> (*) 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.
>> 
>> 2. A scope S has access to a scope T if:
>>   - S is equal to T or is lexically nested within it,
>>   - T is a declaration D and S has access to D, or
>>   - T is a file scope.
> 
> …and S is in the same file?

That would forbid all cross-file accesses.  Remember that this is and'ed with the access to the actual declaration.

> (We never formalized “scope”. Mostly it’s “curly braces, ish”. Not quite 1-1 with “DeclContext”.)

We technically didn't define "lexically nested", either. :)  A formalization of the lookup rules would formalize scope; but yeah, the basic intuition is "curly braces, ish".

> 
>> 
>> 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:
>>   - 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
>>   - the underlying type of a typealias or associatedtype declaration
>>   - the superclass type of a class declaration
>>   - the conformance list of a class, struct, enum, protocol, or extension declaration
>>   - the generic parameters and constraints of a generic declaration
>>   - etc.
>> 
>> 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.
> 
> 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.
> 
> These rules seem correct, but they’re not complete—they’re missing the restriction on witnesses for protocol requirements.

Ah, right.  IIRC those rules are basically along the lines of "there's no potential scope that can access the declaration of the conformance but not the declaration of one of its requirements".

John.

> 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, https://github.com/apple/swift/blob/master/docs/AccessControl.rst <https://github.com/apple/swift/blob/master/docs/AccessControl.rst>.)
> 
> Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/c40c4614/attachment.html>