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)

Start with the tuple-inference examples and the comparison between the explicit tuple annotation and Python-like tuple syntax. The payload names no files, tests, or compiler entry points; completion would require choosing and specifying a syntax that resolves the ambiguity with JavaScript's comma operator, then validating the demonstrated cases.