<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2017, at 14:34, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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="">Responding on the pro side, but I don't endorse this proposal without more details:<br class=""><br class="">~Robert Widmann</div><div class=""><br class="">2017/01/25 13:40、Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">This is contrary to several deliberate design decisions, if I understand correctly.<br class=""><br class="">First, revisions to visibility rules in the Swift 3 timeline were made with the deliberate intention that it should be possible to model greater visibility within a type (e.g. public members) without actually exporting that type. As Swift does not have optional warnings that can be turned off, it would be incongruous if the language also warned users away from creating internal types or variables before they are used. Unlike warnings about unused variables within a scope, which are by definition local, a warning such as proposed would be much more disruptive.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">That decision wasn't really one made to support a deliberate design, but to help make migration of fileprivate easier IIRC (Jordan Rose probably remembers better than I do of the conversation we had about this).</div></div></div></blockquote><div><br class=""></div><div>Saying it's about "migration" is disingenuous. The particular language in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" class="">SE-0025</a> reads:</div><div><br class=""></div><div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The compiler should not warn when a broader level of access control is used within a type with more restrictive access, such as internal within a private type. This allows the designer of the type to select the access they would use were they to make the type more widely accessible. (The members still cannot be accessed outside the enclosing lexical scope because the type itself is still restricted, i.e. outside code will never encounter a value of that type.)</div></div><div><br class=""></div><div>That is, this was a change made to support local design that happened to simplify the rules around access, particularly</div><div><br class=""></div><div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The default level of access control anywhere is internal.</div><div class=""><br class=""></div><div class="">So it still qualifies as "deliberate design".</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></body></html>