[swift-evolution] extending typealiases

Matt Whiteside mwhiteside.dev at gmail.com
Mon Jan 30 22:38:40 CST 2017


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 <dgregor at apple.com> wrote:
> 
> 
>>> On Jan 29, 2017, at 8:35 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution <swift-evolution at swift.org> 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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170130/f8747fd3/attachment.html>


More information about the swift-evolution mailing list