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._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
