<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 30 Jun 2016, at 11:22, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class=""><span class=""><div class=""><div class="">
<div class=""></div></div></div></span></blockquote><blockquote type="cite" class="gmail_quote"><span class=""><div class=""><div class=""><div class=""></div></div></div></span></blockquote></div></div></blockquote><div class=""><div class=""><blockquote type="cite" class=""><span class=""><div class=""><div class=""><div class="">It is an interesting suggestion to use extensions that way,
but how would you nest and create diffrent label pathes with
extensions? </div>
<div class=""><br class=""></div>
<div class="">We also cannot nest extensions (yet) and when it comes to
conformances the access modier is not allowed on extensions. That
is one of my points to remove this behavior from extensions and
have equal access contol on extensions like on classes etc.!</div></div></div></span></blockquote><br class=""></div></div><div class="">How about just allowing more periods in the naming? Like so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct A {}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public extension A.foo {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someMethod() { … } // a.foo.someMethod()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private extension A.foo.bar {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someHiddenMethod() { … } // a.foo.bar.someHiddenMethod() </font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Alternatively:</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>extension A {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public func foo.someMethod() { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private func foo.bar.someHiddenMethod() { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">I suppose it lacks the kind of visual hierarchy that grouping within the type could achieve, but at the same time such grouping could get unwieldy quickly due to implementation details growing the vertical height until the structure becomes unclear. This is why I'd favour extensions personally. There could still be call for both though, as a balance such as simple properties and methods declared hierarchically within the type, vs large methods moved out into extensions, letting us mix and match however we like. I do think that the extension one should be considered though, as it's a recommended way to handle code structure in Swift I think, or at least I'm addicted to using it ;)</div></div></body></html>