<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=""><div class="">I have always found it curious that extensions cannot be named. Since same-file extension are considered to be superior to comments as a way of separating concerns, wouldn’t it make sense to allow naming of extensions? Extension names could possibly be included in symbols for entities in the extension, giving a clue as to the reason for the extension, perhaps. Tools with access to extension names could automatically provide a richer programming environment, without relying upon comments.</div><div class=""><br class=""></div><div class="">Unique names for extensions to protocols and classes would open the door to the ability to selectively suppress some extensions when importing a module, which might be very valuable in complex code bases with name collisions, for example. This can be a real problem for extensions to built-in and foundation types.</div><div class=""><br class=""></div><div class="">Objective C requires inclusion of category headers, thus allowing code to manage “extension” (category) namespaces implicitly.</div><div class=""><br class=""></div><div class="">This seem to be an intensional omission of the part of the core team, but I have never heard the rationale for it. In the case of protocol conformance extensions, a name would probably be redundant, so it would sensible to default the name to the protocol(s) being implemented. Names would have to be optional for backward compatibility. </div><div class=""><br class=""></div><div class="">- Chris</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 9:57 AM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">I don’t understand how extensions help with code locality. It’s literally a matter of <i class="">curly braces</i>. I already glue the extension block to the bottom <span style="font-family:monospace,monospace" class="">}</span> of the protocol block anyway by omitting the empty linebreak.<br class=""><br class=""><span style="font-family:monospace,monospace" class="">protocol Protocol<br class="">{<br class=""> func default_function()<br class="">}<br class="">extension Protocol<br class="">{<br class=""> func default_function()<br class=""> {<br class=""> }<br class="">}</span><br class=""><br class=""></div>as opposed to <br class=""><br class=""><span style="font-family:monospace,monospace" class="">protocol Protocol<br class="">{<br class=""> func default_function()<br class=""> {<br class=""> }<br class="">}</span><br class=""><br class=""></div>I would very much appreciate not having to retype <span style="font-family:monospace,monospace" class="">Protocol</span> and <span style="font-family:monospace,monospace" class="">default_function()</span> over and over. The whole cult-of-same-file-extensions seems to be people refusing to let go of old C++ habits. Have you noticed that nowhere else in Swift is there a concept of separating type declarations from type definitions? That’s because people managed to figure out that typing the same words over and over again doesn’t actually keep code neater at all.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 2, 2017 at 11:27 AM, Gor Gyolchanyan <span dir="ltr" class=""><<a href="mailto:gor.f.gyolchanyan@icloud.com" target="_blank" class="">gor.f.gyolchanyan@icloud.com</a>></span> wrote:<br class=""><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=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 6:15 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-1874922364890104218Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">I agree with this, extensions on types defined in the same file are generally silly, and default implementations belong in the protocol body. I don’t agree with certain style guides prescription of same-file extensions; they should only be used to hide protocol conformances that are “unimportant” to the functionality of the type. In practice this means only conformances like <span style="font-family:monospace,monospace" class="">CustomStringConvertible</span> and <span style="font-family:monospace,monospace" class="">CustomDebugStringConvertible</span> live in extensions.<br class=""><br class=""></div>If you want to group related methods, use linebreaks and whitespace for that. Don’t split up the type braces since that messes up the whole one-set-of-braces == one type definition visual rule.<br class=""><br class=""></div>The only time it ever makes sense to extend a non concrete type that you own is when adding conditional default implementations. Having to extend a bare protocol is the product of a language limitation.</div></div></blockquote><div class=""><br class=""></div></span><div class="">Take a look at my replies to Tino Heth about code locality and the rest...</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 2, 2017 at 6:26 AM, Tino Heth via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><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="">That would work as well, but it has the downside of forcing a potentially huge number of methods to be implemented in a single place, reducing the readability as opposed to packing them into semantically related groups in the form of extensions.</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=""></div></blockquote></span><div class="">I really don't get why people are so obsessed with same-file extensions:<div class="">They are recommended in style guides, influencers blog about them, and they motivated a ridiculous complex change in the access rights system. Yet I haven't seen any evidence that they offer real benefit.</div><div class="">Extensions are great for adding useful helpers to existing types, and still allow you to selectively expose details of your own classes — but most people seem to ignore those options and focus on something can be done better with plain old comments.</div><div class="">[sorry for the rant — but I think a critical look at extensions is long overdue: I rarely see someone questioning their role, so basically, we are making important decisions based on pure superstition]</div><div class=""><br class=""></div><div class="">A protocol itself is already a vehicle to group related methods, and if you have a huge entity, it doesn't get better just because you split it and hide its complexity.</div></div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><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="">Also, please include the original message for reference purposes.</span></div></blockquote></span></div>[hopes Discourse will happen soon ;-) ]</div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>