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

[Jordan Rose]

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/a5eb3a77/attachment.html>