[swift-evolution] Pitch: Limit typealias extensions to the typealias

[David Sweeris]

> On Jun 9, 2017, at 16:38, Daryle Walker via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> 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.
> [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).

Agreed... +1 for something like "newtype", -1 for hoisting that functionality onto "typealias".

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170609/25ceaea1/attachment.html>