suggestion: explicit "tuple" syntax

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)

[rauschma]

@RyanCavanaugh as const worked well in my case (where I needed to pass on a complicated mapped type).

Possibly: Allow as tuple as an alternative syntax when the operand is an Array. Rationale: Expresses the intent better.

[crdrost]

The proposed “radical solution” would mean that in certain circumstances TypeScript is no longer a superset of JavaScript, so it is probably a no-go.

However we could maybe steal F#'s array syntax.

Note that there is a very common circumstance where I’d like to use this, namely map initializers. Right now I have to write in several places,

// in a context where myObjs :: IObject[] and IObject extends {name: string}
const myDict = new Map<string, { seen: boolean, obj: IObject }>();
for (const obj of myObjs) {
  myDict.set(obj.name, { seen: false, obj });
}
// do something that might "see" an obj in myDict
// update the ones that were "seen"
// then remove ones that were not "seen"

Note that I am not using the array initializer because it makes the code much less readable and possibly might hide type errors with the coercive weight of as:

const myDict = new Map(
  myObjs.map(obj => [ obj.name, { seen: false, obj } ] as [ string, { seen: boolean, obj: IObject } ])
);

note that there’s two sources of noise here, the intrinsic noise of the map and the unnecessary noise of telling TypeScript that I meant to write a [string, object] tuple not a (string | object)[] array, and either one of them is readable on its own (the type declaration is no more complex than the type above) but it’s that they have to be joined together which makes this look jarring. So the above keeps the type declaration in exchange for a loop.

If we allow [| ... |] for a tuple constructor, we could do the reverse:

const myDict = new Map(
  myObjs.map(obj => [| obj.name, { seen: false, obj } |])
)

Note that | being a binary operator cannot legally appear directly before ] or after [ so it should preserve the superset-ed-ness?