Repository navigation
Tuples should be clonable with Array.prototype.slice() #4988
Description
Activity
Great idea - after #4910 goes in we can add an overload in lib.d.ts so that
slicewith no arguments returns thethistype.Just added the necessary changes to #4910. When it goes in, all we need is the extra overload in lib.d.ts.
Actually, I'm not so sure about this anymore; if you subclass array, then you definitely aren't going to get the expected behavior when you
.slice().I would not say Subclassing array is the common scenario.
6 remaining items
So the right thing is to do what Daniel Rosenwasser (@DanielRosenwasser) suggested and have a new type to represent the Tuple that extends Array. one thing to note, we would not want to require users to update their library as they update the compiler (as some users have a hand crafted version of the library) so we need to come up with a solution that does not violate this constraint.
I need to go read the spec for tuple types and assignment. Right now I don't understand well enough how the type system supports it. I'll see if I can come up with a proposal afterwards.
After looking at the spec, the relevant section is 3.3.3. It gives an example of a named tuple type:
interface KeyValuePair<K, V> extends Array<K | V> { 0: K; 1: V; }It also says that a type is said to be a tuple-like type if it has a property with the numeric name '0'. Combining these two, I guess we could change the spec to include an explicit tuple type that is the parent of all tuple types:
interface TupleArray<T> extends Array<T> { 0: any }Then KeyValuePair becomes
interface KeyValuePair<K,V> extends TupleArray<K | V> { 0: K, 1: V }The problem with this is that 0's type in TupleArray is
any. If it'sT, thenKeyValuePair's must have a property0: K | V, even though it should be0: K. I thinkanyis OK here because it represents what's going on with Array -- it's not a homogenous array anymore.Now we can take Daniel Rosenwasser (@DanielRosenwasser) 's proposal and put
sliceinsideTupleArray. But to avoid promising thatslicereturns properties from tuple subclasses, per Anders Hejlsberg (@ahejlsberg), we can actually make it returnTupleArray<T>:interface TupleArray<T> extends Array<T> { 0: any; slice: TupleArray<T>; }
The only hole here is that I don't know whether this satisfies Mohamed Hegazy (@mhegazy) 's constraint that users not update their lib.d.ts. Thoughts?
Assuming you meant
slice(): TupleArray<T>that doesn't work because you lose the other numeric properties that make the tuple useful (i.e.1,2, etc.). You'd just end up with a type that has a property0whose type is the union of all types in the original tuple.Closing for now -- we should revisit once we have variadic kinds for tuple types so that there is at least a chance to write a type like:
interface Array<T> { slice<...U>(): ...U; }
...although I'm still not sure how to relate
Tand...Uhere....although I'm still not sure how to relate
Tand...Uhere.You would not (
Tis a union of constituent types in...U), unless tuples get first-class support like here #6229- locked and limited conversation to collaborators
on Jun 19, 2018
Let's say i define a tuple type like this :
Now when i do this:
The compiler complains that
TS2322: Type 'number[]' is not assignable to type '[number, number]'. Property '0' is missing in type 'number[]'.I think it should work, slice without argument (or slice(0) or even slice(0,2)) should allow to clone a tuple.