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

[Xiaodi Wu]

[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`."


> Jordan
>
> On Jun 29, 2016, at 16:51, Jordan Rose <jordan_rose at apple.com> wrote:
>
> I just attended a core team meeting where this whole thing was discussed,
> and will update our amendment
> <https://github.com/apple/swift-evolution/pull/383> tonight. But in short:
>
> - The default access level will be 'internal' everywhere*. The compiler
> will not warn if the access-as-written is broader than necessary. *Motivation:
> it should be possible to design a type's API as if it had more access than
> it currently does.*
>
> * except in extensions, see below
>
> - The complicated "rule 2" from the amendment stands, but possibly in a
> form that isn't specific to 'fileprivate':
>
> 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.
>
>
> 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:
>
> A member may not have a type that references any declarations that aren't
> accessible wherever the member is accessible.
>
>
> I'm concerned about that being *too* permissive, though. I still want
> this to be considered an error:
>
> fileprivate struct Foo {
>   fileprivate typealias Bar = Int
>   internal func baz() -> Bar { … }
> }
>
>
> - An access modifier on an extension has been ruled to indicate the
> desired *scope,* not the desired *access.* Therefore, members within a
> `private extension` will be `fileprivate`. (We're only really getting away
> with this because we don't allow extensions anywhere but at the top level,
> though if we had nested extensions we'd probably consider them scoped
> anyway.)
>
> - We are not looking at renaming either 'fileprivate' or 'private' for
> Swift 3.
>
> - All this has been ruled not to need a formal review.
>
> Thanks everyone for getting us to this point. It'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. :-)
>
> Jordan
>
> P.S. If you see further issues here I'd still like to hear them; if you're
> unclear on any points after I've updated the pull request
> <https://github.com/apple/swift-evolution/pull/383>, I'm happy to go over
> them again.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/ba4a15bb/attachment.html>