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? Previous attempts to do so, which were in part to make possible nested extensions, were rejected.<br><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 15, 2017 at 02:41 Tino Heth &lt;<a href="mailto:2th@gmx.de">2th@gmx.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Thank you for you comment, Xiaodi.</div><div><br></div><div>I understand the disappointment, but imho this proposal is quite different from the ideas that have been rejected, and I hope to be able to convey that standpoint:</div><div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr"><div>One solution to the problem is to remove the use of access modifiers as a shorthand in front of extensions. It was proposed, reviewed, and rejected:</div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md</a></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>The rational for the rejection was that this proposal would eliminate <i>the useful ability to apply access control to a batch of methods and properties.</i></div><div>This can&#39;t be a motivation to discard nested extensions — it does not try to remove batching of access control, but rather extend that ability to be used for stored properties.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div dir="ltr"><div>I tried to follow up with a much milder proposal to change the rules surrounding access modifiers. It was discussed here:</div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024588.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024588.html</a><br></div><div><br></div><div>The PR was here, but rejected for review by the core team:</div><div><a href="https://github.com/apple/swift-evolution/pull/438/files" target="_blank">https://github.com/apple/swift-evolution/pull/438/files</a><br></div></div></blockquote></div></div><div style="word-wrap:break-word"><div>I don&#39;t think this has much similarity either:</div><div>I&#39;m not trying to change extensions itself, but rather leverage their existing capabilities in a bigger context.</div><div><br></div><div>To make it clear:</div><div>A private extension that is nested would would be completely inaccessible (and therefor useless) unless you have at least one member in it whose access level is set to internal (or more accessible).</div></div></blockquote></div>