> On Jun 9, 2017, at 16:38, Daryle Walker via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> 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).
Agreed... +1 for something like "newtype", -1 for hoisting that functionality
onto "typealias".
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
