> On Jun 15, 2016, at 10:46 PM, Robert Widmann <devteam.cod...@gmail.com> wrote:
>
> That is a different discussion entirely. Once you fall below internal then
> we do not default to internal, we default to the maximum access level of the
> outer decl. Read that linked part of the type checker if you don't believe
> me. I also had to fix several hundred lines of SwiftPM and corelibs code
> that was failing to build because of this exact access control schema in
> apple/swift#3000. You'll notice I effectively changed two lines in Sema and
> this was the fallout. I did nothing special to change our existing access
> control mechanism, it's just how it has always worked. Try declaring this
> explicitly and see the diagnostic we emit, then it'll be easier to see why
> this is a problem:
>
> private struct X {
> internal var x : String = "" // expected-warning
> }
>
> ~Robert Widmann
The statement was that "They do not default to ‘internal' when unannotated,
they default to the highest possible access level they can get given the decl
they're in.” This is demonstrably untrue, since if the type they’re in is
public, the highest possible access level they could get would be public, and
unannotated properties in a public type are *not* public. They are internal.
> On Jun 15, 2016, at 10:49 PM, Robert Widmann <devteam.cod...@gmail.com> wrote:
>
> Also consider what would happen if we did allow access control to escalate
> here: Suppose that code did not emit a diagnostic, then the member is still
> private because you cannot reference the class outside of file scope.
Which is… exactly what we want.
> You see, even if we did escalate access control for unannotated members, even
> if we did that (which we don't) you wouldn't even be able to reap the
> benefits. It makes no sense.
A good way to think of it is in terms of what permissions are *removed* by the
access modifiers, rather than *added*. Then, everything makes perfect sense:
Public removes nothing.
Internal removes access outside a module.
Fileprivate removes access outside a file.
Private removes access outside a declaration.
If you have an internal property within a public type, the “public” modifier
removes nothing, and the “internal” modifier then removes access from outside
that module. The result is access from only within the module.
If you have an internal property within an internal type, the “internal”
modifier on the type removes access from outside the module, and then the
“internal” modifier on the property would remove access from outside the
module, except that such access is already removed. Result is access from only
within the module.
With an internal property inside a private type within another type, the
“private” modifier on the type removes access from outside its parent type, and
the “internal” modifier removes access from outside the module—but since no
entities outside the type’s parent type currently have access, and since the
parent type is in the current module anyway, this once again has no effect.
Result is that the property is only accessible from inside its parent type.
With an internal property inside a private type that’s at the top of the file’s
scope, the “private” modifier on the type removes access from outside the file,
and the “internal” modifier removes access from outside the module—but since no
entities outside the file currently have access, and since the file is in the
current module, this once again has no effect. Result is that the property is
only accessible from inside the current file.
And etc.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
