<div dir="ltr">On Sat, Apr 15, 2017 at 10:23 AM, Tino Heth <span dir="ltr"><<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> I think you misunderstand. The rules of access modifiers do not currently work with nested extensions without modification. How do you intend to modify the rules?<br>
</span>There are no nested extensions now, right? So there are also no rules for their access modifiers, if I'm not missing something fundamental (which might be the case — please elaborate on this if my assumptions are wrong).<br>
<br>
Afaik, the ideas you mentioned wanted to change how access modifiers of extensions work, whereas I don't want to change any of their rules.<br>
I even don't want to add any new rules:<br>
Just like today, an extension would introduce a separate scope, and the only meaning of its access modifier would be to act as the default for all elements of this extension.<br>
<br>
The single change for nested extensions compared to regular ones would be the treatment of private (which changes the default for members to fileprivate, so it's rather inconsistent anyways, and not a real new rule, but rather removal of an exception).<br>
This change wouldn't be necessary, but it would be inconvenient to manually mark the majority of its members as private.<br></blockquote><div><br></div><div>I think you misunderstand how access modifiers currently work with extensions. It is not permitted to use an access modifier inside an extension that is higher than that of the extension itself. I pushed for this rule not to be the case, in SE-0025, and in subsequent discussions, as you saw. That was not accepted. Therefore:</div><div><br></div><div>```</div><div>private extension Foo {</div><div> internal func bar() { } // this is a compiler error, because internal > top-level private</div><div>}</div><div>```</div><div><br></div><div>It is not an exception to default members to `fileprivate` inside a `private` extension. It is the only solution, but it only works for top level extensions:</div><div><br></div><div>```</div><div>private extension Baz {</div><div> fileprivate func boo() { } // this is allowed, because fileprivate == top-level private</div><div>}</div><div>```</div><div><br></div><div>There is no way to spell the access level of a nested private extension:</div><div><br></div><div>```</div><div>private struct S {</div><div> private extension {</div><div> func f() { } // what is the access level of `f`?</div><div> }</div><div>}</div><div>```</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">If `f` is private, then it is invisible outside the extension. But `f` cannot be `fileprivate`, because `fileprivate` is more visible than the private extension and is therefore not allowed.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>