[swift-evolution] Pitch: Limit typealias extensions to the typealias
darylew at mac.com
Fri Jun 9 18:38:12 CDT 2017
> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution <swift-evolution at swift.org> wrote:
> Typealiases can greatly reduce the complexity of code. But I think one change in how the compiler handles them could make them even more powerful.
> Perhaps it would be better if the extension would only apply to the parts of my code where I use the HeaderKey typealias and not to all Strings. This could be a great tool to specialize classes by creating a typealias and adding functionality to it. Another example I can think of is typealiases for dictionaries or arrays with added business logic through extensions (especially since you can't inherit from structs).
> If you want to create an extension that adds functionality to all Strings you could have created an extension for String instead of HeaderKey.
> Please let me know what you think. I'm not sure how complex this change would be.
> I could write a proposal if you're interested.
Isn’t the point of “typealias" is that it does NOT have any change in semantics? The compiler doesn’t even have to acknowledge aliases in any run-time type tables, it just references the existing row of what the alias points to (based on a compile-time type table).
As others suggested, this new semantic could be moved to a new type concept (with a new keyword).
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution