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.
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. Objective C requires inclusion of category headers, thus allowing code to manage “extension” (category) namespaces implicitly. 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. - Chris > On Aug 2, 2017, at 9:57 AM, Taylor Swift via swift-evolution > <[email protected]> wrote: > > I don’t understand how extensions help with code locality. It’s literally a > matter of curly braces. I already glue the extension block to the bottom } of > the protocol block anyway by omitting the empty linebreak. > > protocol Protocol > { > func default_function() > } > extension Protocol > { > func default_function() > { > } > } > > as opposed to > > protocol Protocol > { > func default_function() > { > } > } > > I would very much appreciate not having to retype Protocol and > default_function() 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. > > On Wed, Aug 2, 2017 at 11:27 AM, Gor Gyolchanyan > <[email protected] <mailto:[email protected]>> wrote: > >> On Aug 2, 2017, at 6:15 PM, Taylor Swift <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 CustomStringConvertible and CustomDebugStringConvertible >> live in extensions. >> >> 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. >> >> 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. > > Take a look at my replies to Tino Heth about code locality and the rest... > >> On Wed, Aug 2, 2017 at 6:26 AM, Tino Heth via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> 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. >> >> I really don't get why people are so obsessed with same-file extensions: >> 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. >> 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. >> [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] >> >> 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. >> >>> Also, please include the original message for reference purposes. >> [hopes Discourse will happen soon ;-) ] >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
