[swift-evolution] [Discussion] A Problem With SE-0025?
Jordan Rose
jordan_rose at apple.com
Wed Jun 29 19:08:18 CDT 2016
> On Jun 29, 2016, at 17:04, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> [Resending with fewer recipients due to list rules.]
>
>
> On Wed, Jun 29, 2016 at 6:51 PM, Jordan Rose <jordan_rose at apple.com <mailto: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 { … }
> }
>
> If the default access level is internal everywhere, then the example above being an error would mean that this also becomes an error:
>
> ```
> fileprivate struct Foo {
> fileprivate typealias Bar = Int
> func baz() -> Bar { ... }
> }
> ```
>
> That would, I think, be surprising. Thus, I'd recommend the broader rule. What makes you conclude that it's too permissive?
>
Ah, right, that would break backwards-compatibility. The broader rule it is!
Thanks, Xiaodi.
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/c97df52a/attachment.html>
More information about the swift-evolution
mailing list