<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 10, 2017 at 8:26 AM Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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"><span 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;float:none;display:inline!important" class="gmail_msg">I’m not sure that this solves anything meaningful (whether in relation to SE-0169 or more generally), does it? What advantage does this provide over just declaring the protocol conformance and those methods as a direct part of the parent type? This seems like it would just introduce more indentation, and more lines of code, for zero benefit.</span><br 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"></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg">Well, I'm not overwhelmingly convinced of this whole "we put same-module stuff into extensions" anyways, so it's debatable wether proposals like SE-0169 have any meaningful effects at all… do you think that conformances in same-file extensions have a real benefit? </div></blockquote><div><br></div><div>Yes—as Matthew already stated, it's mostly organizational, but the flexibility is nice to have. I like being able to group functionality of a type not solely within a single set of curly braces or a single file, but sometimes also into separate files if the situation calls for it.</div><div><br></div><div>For example, in Swift protocol buffers we have a handful of types that are called "well-known types" that are generated from their .proto file, but to which we also add a number of convenience initializers/methods. Since the type itself is generated, extensions in separate files let us do this without having to hack the generator with special cases to inline the code into the same file.</div><div><br></div><div>But even outside the generated code use cases, it's nice to just be able to implement helpers or additional "convenience" conformances in separate files named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I find it makes my codebase easier to navigate.</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">If nothing else, nested extensions could save those who actually don'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't we nest extensions?</div></div></blockquote><div><br></div><div>Because types and extensions are quite different beasts, so something that applies to one doesn't necessarily apply to the other. Nesting extensions as you described would seem to be not much different than just flattening the extension's contents into the type directly or moving them out to file-level, with the only difference being that it adds a new scope for the purposes of visibility or getting something like "friend" in C++ (but your example is even more fine-grained than that).</div><div><br></div><div>I don't think that holds its weight. This feels like another case of "let's try to satisfy everyone who's unhappy with some part of Swift visibility by changing a completely different feature to make things fall into place", which I don'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><div><br></div><div>Everyone seems to be striving for a "perfect" level of access control that lets individual types/members dictate precisely what other types/members can access them. I'm not sure if that perfection is attainable or not, but even if it is, I don't think it's something we should strive for. I'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><div><br></div><div>Let'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's clear to me which one I would want dropped on the floor. I don't want perfect to be the enemy of good.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>