Thanks for these explanations.  It sounds like you guys want to build this 
feature so it's just a matter of waiting until it has the priority.   

Until then, every box that gets checked on the generics manifesto is much 
appreciated.

-Matt

> On Jan 30, 2017, at 15:17, Douglas Gregor <[email protected]> wrote:
> 
> 
>>> On Jan 29, 2017, at 8:35 PM, Slava Pestov via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> 
>>> On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> In Swift 3.1, I was happy to see that we can now extend types with concrete 
>>> constraints.  I think one other feature which fits nicely with this new 
>>> capability would be extending typealiases, like this:
>>> 
>>> typealias Vector = Array<Float>
>>> 
>>> extension Vector { 
>>>    ...
>>> }
>>> 
>>> Which currently doesn't compile due to:  "Constrained extension must be 
>>> declared on the unspecialized generic type 'Array' with constraints 
>>> specified by a 'where’ clause”
>>> 
>>> What is other people’s interest level?  How possible would it be to add 
>>> this?
>> 
>> I think this particular case would be pretty easy to add, but there is a 
>> more general case with generic typealiases that requires some thought:
>> 
>> typealias OptionalArray<T> = Optional<Array<T>>
>> 
>> extension OptionalArray {
>>   …
>> }
>> 
>> Without generic typealiases, you might imagine this could be written as 
>> something like
>> 
>> extension <T> Optional<Array<T>> {
>>   …
>> }
>> 
>> I think this is called out in the generics manifesto as a potential future 
>> feature. I’m not sure how much work it would take to add it but I imagine 
>> it’s not entirely trivial.
> 
> The implementation here would probably not be trivial. There are two general 
> issues, the first of which also applies to extending typealiases:
> 
> 1) The type checker doesn’t have a principled way of resolving the name of 
> the extended type, so to correctly look through typealiases would require a 
> bunch of reworking of the way we do lookup there. This would be a fantastic 
> improvement to the compiler and would fix a bunch of bugs with extending 
> nested types, too :)
> 
> 2) There are undoubtedly a number of places in the compiler where we assume 
> that the generic parameters of an extension are the same as the generic 
> parameters of the nominal type, but this will no longer be true if we allow 
> extension of generic typealiases. For example:
> 
> struct Pair<T, U> { }
> 
> typealias Array2<V> = Pair<V, V>
> 
> extension Array2 { // extension has one generic parameter, but Pair has two 
> generic parameters
> }
> 
> It’s likely not *hard* to fix these issues, but it’ll be a game of 
> whack-a-mole throughout the compiler.
> 
>       - Doug
> 
> 
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to