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 <[email protected]> のメッセージ: >> On Jun 15, 2016, at 10:46 PM, Robert Widmann <[email protected]> >> 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 <[email protected]> >> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
