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

[Xiaodi Wu]

Cool. FWIW, even in such a world, I wonder if the conformance needs to be
regarded as `fileprivate`:

In all cases where a private protocol is visible and conformance can be
declared, the protocol's access level would be--

- effectively fileprivate (if both protocol and conformance are declared
top-level)
- and/or private (if both protocol and conformance are declared in the same
scope)
- or unutterably less than fileprivate but more than private (if the
protocol is not declared top-level and the conformance is declared in a
nested scope).

In that last case, private is a less accessible level and all other
modifiers are more accessible, so the hypothetical feature of declaring
conformance with less access remains usable even if the default unutterable
access level stays unutterable.
On Thu, Jun 30, 2016 at 11:19 AM Jordan Rose <jordan_rose at apple.com> wrote:

> On Jun 29, 2016, at 23:34, John McCall <rjmccall at apple.com> wrote:
>
> On Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution <
> 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>
> wrote:
>
>> Updated in 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?
>
> (We never formalized “scope”. Mostly it’s “curly braces, ish”. Not quite
> 1-1 with “DeclContext”.)
>
>
> 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.
>
> 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.)
>
> Jordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/b3b11db4/attachment.html>