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

[Robert Widmann]

Charles we've diverged from the actual issue at hand to nitpick my English.  Read the code (that std::min tho!).  We have a problem here and no obvious solution that doesn't involve special-casing parts of this proposal.  Do you have a solution or shall we take this offline?  I can provide you my iMessage information in a person email if you wish to discuss this with me or any other members of the team, but the list is not the most productive place for this.

Thanks,

~Robert Widmann

2016/06/15 21:04、Charles Srstka <cocoadev at charlessoft.com> のメッセージ:

>> On Jun 15, 2016, at 10:46 PM, Robert Widmann <devteam.codafi at 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.codafi at 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/fc47a2fb/attachment.html>