<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=""><div class="">My understanding of the proposal was that the unannotated properties/methods inside of a scope have the same *visibility* as their surrounding scope, or internal, whichever is less.</div><div class=""><br class=""></div><div class="">That is slightly different than having the same access level. Thus:</div><div class=""><br class=""></div><div class="">private struct Outer {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var inner:Int</div><div class="">}</div><div class=""><br class=""></div><div class="">is different than:</div><div class=""><br class=""></div><div class="">private struct Outer {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private var inner:Int</div><div class="">}</div><div class=""><br class=""></div><div class="">In the first, inner is accessible precisely everywhere where Outer is accessible. In the second, inner is only accessible within Outer itself. It is important that we have the first behavior for unannotated inner, because there is no other way to spell it.</div><div class=""><br class=""></div><div class="">That is my understanding of the intent of SE-0025, even if the exact wording is confusing.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class="">P.S. I would personally like to see unannotated properties/methods inside of a scope have the same visibility as their surrounding scope. Full stop. End of sentence. (It seems to me like the special handling of internal is what is causing the confusion here). That is what I would expect the behavior to be if I didn’t know. That isn’t what was written in the proposal though...</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">While implementing SE-0025 (fileprivate), I noticed an interesting bug in the proposal. Under the implementation outlined there, any top-level structure, class, or enum declared private cannot possibly be instantiated and so cannot be used in any way. Because of this, private top-level declarations are more often than not blown away entirely by the compiler for being unused. It seems strange to me to allow a key language feature to act solely as a hint to the optimizer to reduce the size of your binary. Perhaps the restrictions around private needs to be relaxed or the line between fileprivate and private needs to be investigated again by the community before inclusion in the language.
Thoughts?
~Robert Widmann</pre></blockquote><div class=""><br class=""></div></div></body></html>