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 Ryan Cavanaugh (@RyanCavanaugh) Daniel Rosenwasser (@DanielRosenwasser)
• Proposal: Variadic Kinds -- Give specific types to variadic functions #5453 - variadic kinds /cc Nathan Shively-Sanders (@sandersn) Jason Freeman (@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]

Jason Freeman (@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]

Igor Oleinikov (@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]

Anatoly Ressin (@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]

Anatoly Ressin (@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.