<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 10, 2017 at 9:49 AM 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" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">But even outside the generated code use cases, it&#39;s nice to just be able to implement helpers or additional &quot;convenience&quot; conformances in separate files named appropriately (like &quot;Type+Protocol.swift&quot; or &quot;Type+Helpers.swift&quot;). I find it makes my codebase easier to navigate.</div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">No doubt about the usefulness of having separate files with extensions here</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg" style="word-wrap:break-word"><div class="gmail_msg">If nothing else, nested extensions could save those who actually don&#39;t care much about such issues from another breaking change in Swift — and imho it adds consistency:</div><div class="gmail_msg">We can nest types, so why can&#39;t we nest extensions?</div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">Because types and extensions are quite different beasts, so something that applies to one doesn&#39;t necessarily apply to the other. </div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I don&#39;t buy this argument at all without an objective explanation why the curly braces of extensions should be treated different than the curly braces of types...</div></div></div></blockquote><div><br></div><div>They shouldn&#39;t be. That&#39;s why I don&#39;t support SE-0169 either, because it would allow extensions to extend the *scope* rather than the *type*, but only within the same file. I think that&#39;s fundamentally broken.</div><div><br></div><div>But my comment wasn&#39;t about curly braces—it was about types vs. extensions. For example, you can declare local types within a function, but you can&#39;t extend a type within a function (nor do I think it would be a good idea).</div><div><br></div><div> </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" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">I don&#39;t think that holds its weight. This feels like another case of &quot;let&#39;s try to satisfy everyone who&#39;s unhappy with some part of Swift visibility by changing a completely different feature to make things fall into place&quot;, which I don&#39;t think is a sound motivation or design principle. The example you posted in your initial message weaves multiple types/nesting levels together in a way that looks *incredibly* difficult to follow/parse to even an experienced user of the language.</div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Did you noticed that I started this example as mockery? In real life, I would hopefully never nest more than once… and do you think sprinkling parts of class over the project is easier to follow?</div></div></div></blockquote><div><br></div><div>Depending on the type, yes. I wouldn&#39;t sprinkle the *fundamental/core* parts of a type across the project, but if there&#39;s some kind of &quot;aside&quot; functionality that doesn&#39;t depend on private knowledge of the type, then I find it to be a nice feature to have. It requires me to have reasonable names to my source files, but that&#39;s not a significant burden.</div><div><br></div><div> </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" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">Everyone seems to be striving for a &quot;perfect&quot; level of access control that lets individual types/members dictate precisely what other types/members can access them. I&#39;m not sure if that perfection is attainable or not, but even if it is, I don&#39;t think it&#39;s something we should strive for. I&#39;d rather have a simple visibility model that leaks a little than an air-tight model that allows people to write overly complicated code for the sake of fine-tuning access.</div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I had no desire to change the model of Swift 2 — but apparently, others thought it wasn&#39;t sufficient, and I&#39;d rather prefer a conceptually simple model like nesting over a complicated one with less power.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">Let&#39;s remember that the core team has limited resources to implement the things we propose, and if I have to choose between, say, serialization, reflection, asynchronous constructs, and rehashing visibility levels yet again, it&#39;s clear to me which one I would want dropped on the floor. I don&#39;t want perfect to be the enemy of good.</div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"></div>Well, right now, there are several (at least one ;-) proposals that aim for a breaking change of the whole model… nested extensions break nothing, so it can be delayed for as long as the core team likes, without causing any trouble.</div></blockquote><div> <br></div></div></div>