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?
Seems totally fair to add if someone wants to devote the time and effort to
implement it, but also easily worked around for the moment and therefore
(IMO) not a pressing issue.
···
On Sun, Jan 29, 2017 at 3:03 PM, Matt Whiteside via swift-evolution < swift-evolution@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?
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.
Slava
···
On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:
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
···
On Jan 29, 2017, at 8:35 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.
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@apple.com> wrote:
On Jan 29, 2017, at 8:35 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution <swift-evolution@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.