[Resending with fewer recipients] On Wed, Jun 29, 2016 at 8:55 PM, Jordan Rose <jordan_r...@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_r...@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. > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution