<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Thanks,</div><div id="AppleMailSignature"><br>~Robert Widmann</div><div><br>2016/06/15 21:04、Charles Srstka <<a href="mailto:cocoadev@charlessoft.com">cocoadev@charlessoft.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 10:46 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">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:</div><div class=""><br class=""></div><div class="">private struct X {</div><div class=""> internal var x : String = "" // expected-warning</div><div class="">}<br class=""><br class="">~Robert Widmann</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 10:49 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>Which is… exactly what we want.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">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. <i class="">It makes no sense.</i></div></div></div></blockquote></div><div><br class=""></div><div><div class="">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:</div><div class=""><br class=""></div><div class="">Public removes nothing.</div><div class="">Internal removes access outside a module.</div><div class="">Fileprivate removes access outside a file.</div><div class="">Private removes access outside a declaration.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">And etc.</div></div><div><br class=""></div><div>Charles</div><div><br class=""></div></div></blockquote></body></html>