Proposal: strict and open-length tuple types

[Igorbek]

Update: converted to proposal.

Background

Currently, tuples are arrays that are restricted in minimum length, but not in maximum:

var t1: [number, number] = [1]; // this doesn't work
var t2: [number] = [1, 2]; // this works

This makes harder to predict types or errors in some scenarios:

var t1: [number, string];
var t2 = [...t1, ...t1]; // could be inferred to be [number, string, number, string], but must be inferred as [number, string] (now it's simply inferred as (number|string)[])

var t3: [number, string] = [1, "a"];
t3[2]; // ok, but must be an error

There also might be difficult to adopt variadic kinds, especially in type construction:

function f<...T>(...rest: [...T]): [...T, ...T] {
  var rest1: [...T] = [...rest, 1]; // it will be acceptable due to current rules
  return [...rest1, ...rest1]; // due to types it seems to be [...T, ...T], but actually is [...T, number, ...T, number]
}

Proposal

(1) Restrict tuple instance to match exact length

var t1: [number, string] = [1, "a"]; // ok
var t2: [number, string] = [1]; // error (existing)
var t3: [number, string] = [1, "a", "b"]; // error (new)

(2) Introduce open length tuple types

Open-length tuple types will be the same as tuple types are now.

var t1: [number, string, ...] = [1, "a", 2, "b"]; // same as current tuples are now
var t2: [number, string, ...(number|string|boolean)[]]; // explicitly type rest elements -- syntax option 1 -- consistent with rest parameters
var t3: [number, string, ...number|string]; // explicitly type rest elements -- syntax option 2

// strict tuple type can be implicitly converted to open length tuple type
var t4: [number, string, string];
var t5: [number, string, ...] = t4; // ok
var t6: [number, ...] = t4; // error, 'number|string' cannot be converted to 'number'
var t6: [number|string, ...] = t4; // ok
var t7: [number, ...(number|string)[]] = t4; // ok

(3) Improve contextual type inference for spread operators on tuples

var t1: [number, string];
var t2: [number, string, number, string] = [...t1, ...t1]; // it's proven now

var t3: [number, ...];
var t4: [string, ...];
var t4: [number, number|string, ...] = [...t3, ...t4]; // this also can be proven

Related issues

This addresses:

• out of range index in a tuple magically works #5203 - out of range index in a tuple magically works /cc @Aleksey-Bykov @RyanCavanaugh @DanielRosenwasser
• Proposal: Variadic Kinds -- Give specific types to variadic functions #5453 - variadic kinds /cc @sandersn @JsonFreeman

Disadvantages

This is definitely a breaking change.

[Igorbek]

Any thoughts on this? Do you think it could be proposed?

[JsonFreeman]

You'd still have the problem of calling push or pop on the tuple. Or these subtler variants:

array[array.length] = 0;
array.length--;

[zpdDG4gta8XKpMCd]

just a personal observation, as of now the following way of doing tuples gets more predictable results than the official tuples that are mostly arrays

interface T2<a, b> {
    0: a;
    1: b;
}
function t2 <a, b>(one: a, two: b) : T2 <a, b> {
    return <any> [one, two];
}

[Igorbek]

@JsonFreeman hm, fair. However we have similar things that can cheat type system. Such as array variance.

var animals: Animal[] = dogs;
animals.push(cat);
dogs[dogs.length-1].woof(); // boom

BTW, array.length-- breaks existing rules too.

Option 1 - restrict such operations on fixed-length tuples. So let's say if array boundaries wasn't proven - give an error.
Option 2 - allow to shoot the leg, as we do in other cases.

[dead-claudia]

By the way, 👍 for this proposal. It seems to me a necessity for solving the problem with variadic types. No matter how you try to solve the variadic problem (I've seen several ideas already), this comes up and gets in the way every single time.

[Artazor]

Ability to distinguish strict tuples and open tuples looks reasonable.

[dead-claudia]

@Igorbek My opinion on that:

• Option 1: Always require <Animal[]> <any> dogs for that. I've used that trick before to cheat the type system (it couldn't tell I was actually doing something that was type-safe a few times). Fixed-length tuples should only have a subset of the Array operations (push/pop should not exist on the type even though they technically exist, for example).
• Option 2: I'd be okay with open-ended tuples being a true subtype of arrays.

[Artazor]

@isiahmeadows

Fixed-length tuples should only have a subset of the Array operations

Agree.
Moreover, it seems to me that fixed-length tuples are needed only in read-only scenarios...

[dead-claudia]

@Artazor There are times when it's nice to be able to write to a tuple. It's not frequent, but it's occasionally helpful. I would be okay with copyWithin with limited semantics. The biggest reason I'm interested in fixed-length tuples is that it would help solve the variadic problem with bind tremendously (that combined with non-strict type checking).

[Artazor]

@isiahmeadows
Imagine, that [T1,T2,T3] means strict tuple. Let's try to write a problematic code:

var a: [number, boolean] = [1, true] //strict
var b: [number, boolean, number, boolean] //strict
b = [...a, ...a] // ok
a[0] = 2; // ok (statically)
b = [...a, ...a] // still ok
a[a[0]] = 3; // can we prevent this at compile time? (doubt)
b = [...a, ...a] // oops!

[dead-claudia]

@Artazor

I feel it should be restricted to n-tuples of just a single type. As for indexed access, it should be unsafe, because otherwise it's much more complicated for the compiler, and if you're resorting to this over plain objects in most cases, either the code probably already smells of feces (little the language can do to help you here), or you know what you're doing, and need that indexed access for performance reasons (e.g. an 8-entry table, which the compiler will infer).

As for varying types, it should be read-only, but unsafe read access is pretty much the only way to do it in practice. Otherwise, it's unnecessary boilerplate outside of destructuring. Matter of fact, in many of these kinds of cases, Haskell prefers crashing over returning a Maybe, since it's far faster and chances are, you probably already have an idea whether your index is within range.

Remember, you can only do so much statically - some things are literally undetectable until runtime, no matter how powerful your type system is.

[JsonFreeman]

I agree with the general sentiment of wanting fixed length tuples. The reason I am worried about the length of the tuple not being perfectly enforceable is that if it is used to solve the variadic bind typing, you won't just get a tuple/array of the wrong length. You'll get a function with the wrong number of arguments! For some reason that seems a lot worse to me than a tuple of the wrong length, or even arguments of the wrong types.

[dead-claudia]

@JsonFreeman That's one of the main reasons I want fixed-length tuples. Using tuples for variadic types won't be a problem with fixed-length tuples. Plus, it's more type safe, which is always a plus. If you're okay with open-ended tuples that subtype Arrays, in which the length can change, it's probably better to be explicit about that.

(I'd rather opt out of type safety than in.)

[JsonFreeman]

I agree with that, my point is that you still have to be okay with the tuple length being wrong in a case like this.

[dead-claudia]

@JsonFreeman I did suggest removing the mutating methods from the fixed-length tuple interface.

[Igorbek]

@isiahmeadows I'd say would be better to remove length-mutating methods only, such as push, pop, and make length readonly. However, it would be still able to assign to a open-length tuple variable and mutate its length.

[dead-claudia]

Oh, and you might want to include splice as well. That can mutate length.

On Thu, Mar 10, 2016, 14:13 Isiah Meadows [email protected] wrote:

I meant that implicitly... Sorry about that.

On Thu, Mar 10, 2016, 14:12 Igor Oleinikov [email protected]
wrote:

@isiahmeadows https://github.com/isiahmeadows I'd say would be better
to remove length-mutating methods only, such as push, pop, and make
length readonly. However, it would be still able to assign to a
open-length tuple variable and mutate its length.

—
Reply to this email directly or view it on GitHub
#6229 (comment)
.

[dead-claudia]

I meant that implicitly... Sorry about that.

On Thu, Mar 10, 2016, 14:12 Igor Oleinikov [email protected] wrote:

@isiahmeadows https://github.com/isiahmeadows I'd say would be better
to remove length-mutating methods only, such as push, pop, and make length
readonly. However, it would be still able to assign to a open-length tuple
variable and mutate its length.

—
Reply to this email directly or view it on GitHub
#6229 (comment)
.

[Artazor]

Interesting, that these problems are expressible in the following way:
If one value type B extends memory layout of the other value type A, then actually only the reference to the first type B* is the subtype of the reference to the second one A* (compare with inheritance in C++). As we know arrays in JavaScript are reference types (not a value types), at the same time fixed length tuples capable of being used in variadic equations resolution should be value types. That is why @JsonFreeman has intuition that tuples are subtype of arrays.

[dead-claudia]

@Artazor That seems about right AFAICT.

[JsonFreeman]

The way tuples are defined in TypeScript entails that they are subtypes of arrays. This is intuitive, and it works pretty well in most cases. But it definitely has its problems, and the variadic matching is indeed one of those problems.

[dead-claudia]

Now that I think about it, array literals should be castable + assignable to Array as well as all tuple types, and this will have to be doable on the language level. Otherwise, you have a huge back-compat problem.

// If either of these fail, that's a lot of existing code breakage.
let list1 = <number[]> [1, 2, 3]
let list2: number[] = [1, 2, 3]

Just a thought. That's all.

[ghost]

Can we also have optional tuple elements? E.g. [ number, number? ].

Similar to [ number ]|[ number, number ] except not an error to use in destructuring. E.g.

const foobar: [ number ]|[ number, number ] = [ 1 ],
    [ foo, bar = undefined ] = foobar; // currently an error

Similar to [ number, number|void ] except not an error to assign [ number ]. E.g.

const foobar: [ number, number|void ] = [ 1 ]; // currently an error

[dead-claudia]

@errorx666 [number, number?] is already a valid type now, and it carries similar semantics to [number, number|void].

Also, I'm not entirely convinced optional tuple elements are even a necessary feature.

[ghost]

@isiahmeadows: Neither of those types allow [ 1 ]. I ran into a use-case where I wanted an array of exactly one or exactly two numbers. The two solutions I tried (shown above) both resulted in compilation errors (despite working fine in the emit).

[KiaraGrouwstra]

I tried t3, but failed:

var t3b: { 0: number, 1: string } = [1, "a"];
t3b[2]; // still no error, and can't overwrite the numerical index to anything stricter than `number | string` :(

Interestingly it does error if you try this member access on the type level instead. This means alternatives where the operation would be specified through a typing, such as _.get or R.prop, could serve as type-safer alternatives to regular member access. That seems more verbose, but with currying + function composition has its pros as well.

As to making this fail:

var t5: [number, string] = [1, "a", "b"]; // error (new)

It seems RHS tuples can take extra properties, objects can't. If I can fix TupleToObject, maybe this would do:

type AddPrototype<T> = Pick<T, keyof T>;
type ArrProto<T extends any[]> = AddPrototype<T> & {
    [Symbol.iterator]: () => IterableIterator<T[-1]>,
    [Symbol.unscopables]: () => { copyWithin: boolean; entries: boolean; fill: boolean; find: boolean; findIndex: boolean; keys: boolean; values: boolean; }
} & { [i: number]: T[-1] };

var t1: [number, string] = <ArrProto<[1, "a"]>>[1, "a"];
// ^ ok
// v we're good if one of these errors. a/b don't, and c/d/e still break from the `TupleToObject` bug...
var t5a: [number, string] = [1, "a", "b"];
var t5b: [number, string] = <ArrProto<[1, "a", "b"]>> [1, "a", "b"];
var t5c: TupleToObject<[number, string]> = [1, "a", "b"];
var t5d: TupleToObject<[number, string]> = <TupleToObject<[1, "a", "b"]>> [1, "a", "b"];
var t5e: TupleToObject<[number, string]> = <ArrProto<[1, "a", "b"]>> [1, "a", "b"];

Still explicit conversions, type dependencies, non-DRY on the expression level, still broken, and t3... isn't ideal either. :/

[KiaraGrouwstra]

well, I got t3 to error at least, though it ain't pretty:

export type Obj<T> = { [k: string]: T };
export type TupleHasIndex<Arr extends any[], I extends number> = ({[K in keyof Arr]: '1' } & Array<'0'>)[I];
// ^ #15768, TS2536 `X cannot be used to index Y` on generic
export type ObjectHasKey<O extends {}, K extends string> =
    ({[K in keyof O]: '1' } & Obj<'0'>)[K];
export type NumberToString = ['0','1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','25','26','27','28','29','30','31','32','33','34','35','36','37','38','39','40','41','42','43','44','45','46','47','48','49','50','51','52','53','54','55','56','57','58','59','60','61','62','63','64','65','66','67','68','69','70','71','72','73','74','75','76','77','78','79','80','81','82','83','84','85','86','87','88','89','90','91','92','93','94','95','96','97','98','99','100','101','102','103','104','105','106','107','108','109','110','111','112','113','114','115','116','117','118','119','120','121','122','123','124','125','126','127','128','129','130','131','132','133','134','135','136','137','138','139','140','141','142','143','144','145','146','147','148','149','150','151','152','153','154','155','156','157','158','159','160','161','162','163','164','165','166','167','168','169','170','171','172','173','174','175','176','177','178','179','180','181','182','183','184','185','186','187','188','189','190','191','192','193','194','195','196','197','198','199','200','201','202','203','204','205','206','207','208','209','210','211','212','213','214','215','216','217','218','219','220','221','222','223','224','225','226','227','228','229','230','231','232','233','234','235','236','237','238','239','240','241','242','243','244','245','246','247','248','249','250','251','252','253','254','255'];
export type Inc = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256];
export type Overwrite<K, T> = {[P in keyof T | keyof K]: { 1: T[P], 0: K[P] }[ObjectHasKey<T, P>]};
export type TupleToObject<R extends any[], I extends number = 0, Acc = {}> =
    { 1: TupleToObject<R, Inc[I], Overwrite<Acc, { [P in NumberToString[I]]: R[I] }>>, 0: Acc }[TupleHasIndex<R, I>];

const foo: [1, "a"] = [1, "a"]; // no cast with #16389
var t3: TupleToObject<typeof foo> = foo;
t3[2]; // error with `noImplicitAny`: Element implicitly has an 'any' type because type ... has no index signature.

[KiaraGrouwstra]

Well, Ramda typings also just ran into this issue, typed-typings/npm-ramda#173 (comment). Specifically, after a function overload asking for a higher-length tuple failed, it fell through to an overload asking for a unary tuple, which then matched, going against desired behavior. Not seeing clear alternatives (based on overloads) that could do without this.

[KiaraGrouwstra]

Potential solution, tie tuples to a new Tuple interface (sub-typing ReadOnlyArray), following the suggestion by @mhegazy at #16503 (comment), such as to specify known length. I'd imagine the distinct length literals would prevent one from assigning higher-length tuples to lower-length ones, as suggested here.

interface Tuple<TLength extends number, TUnion> extends ReadonlyArray<TUnion> {
    length: TLength;
}

The obvious question here seems whether ending this assignability would break much in practice. Seems worth finding out.

Then again though, in other areas like implicit JS casts like Number -> String TS's stance appears to have been that explicit conversions beat implicit magic, and I suppose it might not be unreasonable to extend that reasoning to this tuple case as well.

[KiaraGrouwstra]

I've just opened a WIP PR based on the explicit length idea at #17765. I think I'm half-way, but feel a bit stuck about how to properly get the tuples to derive from this interface; input welcome.

[KiaraGrouwstra]

Update: got it to work. Using a flag for those concerned about breaking change, so should be win-win.

[mstn]

@tycho01 I used your trick with length here and I was able to define a type for arrays of generic fixed size. It is a bit hacky, but it seems to work in some common use cases. I do not know if this application is known or if it can be reduced to your work without defining a new interface as I did.

[KiaraGrouwstra]

@mstn: I hadn't tried that -- I've no idea how your 0 workaround managed to beat the type widening issue!
That said, it seems to work also as the simplified type FixedSizeArray<N extends number, T> = { 0: any, length: N } & ReadonlyArray<T>?

[mstn]

Yes, you are right. Actually, the default 0 for M yields nothing else but { 0: any }!

The trick works only for tuple and not for the corresponding objects. Moreover, it works only with 0 (or a sequence 0, 1, ...) and not with non "sequential" keys. It fails for tuple types, of course.

Is it a bug or a feature?

type A = { 0: any };

let a1: A = ['a', 'b']; // ok
let a2: A = { 0: 'a', 1: 'b' }; // error

type B = { 1: any };

let b1: B = ['a', 'b']; // error
let b2: B = { 0: 'a', 1: 'b' }; // error

type C = { 0: any, 1: any };

let c1: C = ['a', 'b', 'c']; // ok
let c2: C = { 0: 'a', 1: 'b', 2: 'c' }; // error

type D = [any];

let d1: D = ['a']; // ok
let d2: D = ['a', 'b']; // error

[mstn]

If we think in Javascript, an array is an object with sequential numerical keys. Hence, expressions like a1 or c1 are a sort of upcasting. The Typescript compiler is smart enough to understand it! So I think it should be a feature. What do you think?