> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution > <swift-evolution@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. [SNIP] > 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). — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
