suggestion: explicit "tuple" syntax

[boneskull]

Problem

I'm writing this after encountering (what I think is) #3369. I'm a noob to TS, so I apologize for any misunderstandings on my part. The behavior the lack of type inference here:

interface Foo {
  bar: [number, number];
}

interface McBean {
  baz: Foo;
}

// error: McMonkey does not implement McBean
class McMonkey implements McBean {
  baz = {
    bar: [0, 1]
  };
}

// vs

// no error
class McMonkey implements McBean {
  baz: Foo = {
    bar: [0, 1]
  };
}

Because array literals are (correctly) inferred to be arrays, TS is limited in its ability to infer "tuple". This means there's an added overhead to working with tuples, and discourages use.

As I see it, the problem is that a tuple is defined using array literal notation.

A Conservative Solution

Adding a type query (?) such as tuple (.e.g tuple) would be better than nothing:

class McMonkey implements McBean {
  baz = {
    bar: <tuple [number,number]> [0, 1]
  };
}

...but this is still clunky, because you'd have to use it just as much as you'd have to explicitly declare the type.

A Radical Solution

There's a precedent (Python) for a tuple syntax of (x, y). Use it:

interface Foo {
  bar: (number, number);
}

interface McBean {
  baz: Foo;
}

class McMonkey implements McBean {
  baz = {
    bar: (0, 1)
  };
}

Obvious Problem

The comma operator is a thing, so const oops = 0, 1 is valid JavaScript. 0 is just a noop, and the value of oops will be 1. Python does not have a comma operator (which is meaningful in itself).

I've occasionally used the comma operator in a for loop, similar to the MDN article. Declaring var's at the top of a function is/was common:

function () {
  var a, b, c;
}

Parens are of course used in the syntax of loops and conditionals, as well as a means of grouping expressions.

A nuance of Python's tuples are that they must contain at one or more commas, which could help:

foo = (0) # syntax error or just `0`; can't recall
foo = (0,) # valid tuple

...or it could actually make matters worse, because (0, ) is an unterminated statement in JavaScript.

That all being said, using the suggested Python-like syntax, it seems difficult but possible for the compiler to understand when the code means "tuple" vs. when it doesn't.

---

I'd be behind any other idea that'd achieve the same end. I don't know how far TS is willing to diverge from JS, and I imagine significant diversions such as the above are not taken lightly.

(I apologize if something like this has been proposed before; I searched suggestions but didn't find what I was looking for)

[DanielRosenwasser]

Very related to #10195

[boneskull]

Similar syntax suggestion; different purposes.

As a former TypeScript-hater & JavaScript purist, I can tell you the verbosity was a turnoff. Expanding the inference capabilities of TS -- and subsequently featuring them! -- would make it easier to approach & use for many like myself.

[jcalz]

Just FYI, your conservative solution already works if you leave off the word tuple:

class McMonkey implements McBean {
  baz = {
    bar: <[number, number]> [0, 1]  // no error
  };
}

but I understand you'd rather put typescript through the Annotation-Off Machine.

[arturkulig]

This is valid TS:

const a: [string, string] = ['a', 'b', 'c']
const b: string[] = ['a'] as [string, string]

It can be dealt with, but requires caution and discipline, which ideally TS should not require for types.

Proposal: infer literal types from literal array notation

[boneskull]

@jcalz Right; perhaps then what I should have suggested is a tuple built-in type, like object.

When speaking of annotations, without a doubt, the best types are the types without.

[masaeedu]

Perhaps we coud break a portion of the the Array interface out into a ReadOnlyArray interface, which Array would extend, and provide some syntax (I have no preference here, as an example perhaps `["foo", "bar"] or <readonly>["foo", "bar"]), to create ReadOnlyArray literals. Since the elements of a ReadOnlyArray are not mutable positions (by virtue of the limited API it exposes), they may safely be inferred as literals.

This breakup of Array would be necessary anyway for work on co/contravariance.

[RyanCavanaugh]

@masaeedu https://github.com/Microsoft/TypeScript/blob/master/lib/lib.d.ts#L986

function ro<T>(x: Array<T>): ReadonlyArray<T> {
    return x;
}

const j = ro([1, 2, 3]);
j[0] = 10; // Error
j.push(11); // Error

[masaeedu]

@RyanCavanaugh Awesome! That means we're almost there, but j is still not being inferred as [1, 2, 3]. That's probably because the expression [1, 2, 3] widens to number[] and irrevocably throws away the type information.

It'd be nice if the compiler was happy with the following:

// Spread args are not allowed to be ReadOnlyArray :(
function ro<T>(...args: ReadOnlyArray<T>) {
    return args;
}

// Safe to infer readonly equivalent of [1, 2, 3] tuple type for j!
const j = ro(1, 2, 3);

[tvald]

You can simulate a built-in Tuple type via the following:

function Tuple<T1, T2, T3, T4, T5>(t: [T1, T2, T3, T4, T5]): [T1, T2, T3, T4, T5]
function Tuple<T1, T2, T3, T4>(t: [T1, T2, T3, T4]): [T1, T2, T3, T4]
function Tuple<T1, T2, T3>(t: [T1, T2, T3]): [T1, T2, T3]
function Tuple<T1, T2>(t: [T1, T2]): [T1, T2]
function Tuple<T1>(t: [T1]): [T1]
function Tuple(t: any): any { return t }

const x = Tuple([1, '', {}, 1]) // [number, string, object, number]

Note that the longer definitions do need to come first.

[tvald]

Built-in language support for an explicit Tuple (or tuple) type would be highly desirable.

Aggressive conversion of tuples to arrays is a common problem. See also: #3369, #8276, #15071, #16389, #16503, #16700... more

At present, it's hypothetically possible to explicitly annotate a tuple everywhere it would be converted to an array, but that's only feasible if (a) you can/have imported the element type definitions, and (b) they aren't a mess of unioned or anonymous types.

[KiaraGrouwstra]

In that #16389 I argued to have const infer const x = [1, '', {}, 1] to be of type [1, '', {}, 1] (as opposed to [number, string, object, number] mentioned in the Tuple suggestion above), and ditto for objects, mirroring how const already infers literals for primitives.
Retaining all info this way matters for e.g. Ramda's path function, which would use the literals to navigate a given structure.

The primary counter-argument found there was granular types would break Array.prototype.push, which I believe could be fixed with a push overload on a tuple interface in lib.d.ts.

Am I missing any flaws there?

[aluanhaddad]

@tycho01 that's kind of an awesome idea and it would open up so many scenarios that are valuable but at the same time it would be a massive breaking change.

[KiaraGrouwstra]

@aluanhaddad: perhaps if we know what else might break we could tackle them one by one? If the workarounds could be as simple as adding tuple interfaces to lib.d.ts, then great.

[aluanhaddad]

For tuples that might be all it would take, and could quite well be worth it at that point but I guess I was thinking of it in a more generalized form that would apply to the top level properties of object literals as well.

In general I don't use classes and favor a style making heavy use of standard functions, object literals, arrays, and {...x}. A big pain point is not getting literal type inference on any object literal properties. Since I don't reassign them I would like them to be literal types so that I can take advantage of CFA (especially exhaustiveness checking) and improved type-inference. I probably just need to use more helper libraries like Ramda 😁