Make tuples have known length

[KiaraGrouwstra]

Add fixed length for tuples following @Aleksey-Bykov's a suggestion in #13239.
Fixes #6229, so [number, number] would not match [number] (length 2 wouldn't match 1).
I put this behind a strictTuples flag so people can also still use the old behavior.

[aluanhaddad]

Shouldn't the length property of the new interface be readonly?

[zpdDG4gta8XKpMCd]

practically it doesn't have to be, consider:

interface X { length: 0; }
const x: X = { length: 0 };
x.length = Math.random(); // <-- type error
x.length = 1; // <-- type error
x.length = 0; // <-- allowed, but why?

[KiaraGrouwstra]

It hadn't occurred to me; Array was missing readonly from length too. Adding it there makes it not compile anymore, but on Tuple it's fine, and seems consistent with most other interfaces with length-like properties. I'll go along then.

[dead-claudia]

I'd probably add readonly length: TLength just to be a little more semantically descriptive of the type, even if it doesn't really affect anything in practice.

Note that for dumb reasons, readonly is assignable to read-write types, but that's already been reported by someone else.

[KiaraGrouwstra]

@isiahmeadows: Yeah, changed it.

I feel a bit on the fence about #13347; I hope assignability from this Tuple -> ReadonlyArray -> arrays, if viable, could facilitate granular inference through #17785.

[KiaraGrouwstra]

Update: should be good now, ready for feedback.

[KiaraGrouwstra]

Travis randomly complaining:

npm ERR! code EPEERINVALID
npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants typescript@>=2.1.0 || >=2.1.0-dev || >=2.2.0-dev || >=2.3.0-dev || >=2.4.0-dev || >=2.5.0-dev || >=2.6.0-dev
npm ERR! peerinvalid Peer [email protected] wants typescript@~2.0.3 || >=2.0.0-dev || >=2.1.0-dev || >=2.2.0-dev || >=2.3.0-dev || >=2.4.0-dev || >=2.5.0-dev

[ikatyang]

Tests should be fixed by ivogabe/gulp-typescript#536.

[KiaraGrouwstra]

Merged for retry, Travis seems good again. Thanks @ikatyang.

[sandersn]

I like this change, but I'm going to try implementing tuple-freshness first to see if it works well too.

[sandersn]

I don't see how adding Readonly helps if the type is literally 2, because only 2 can be assigned to it. If the intent is future-proofing in case Readonly will someday propagate through assignments, I think that it's as likely to harm as it is to help.

[KiaraGrouwstra]

Yeah, fair enough. I had no special intentions in adding it. Feel free to adjust as you see fit! :)

[sandersn]

• Only one additional error in firebase, but it's the same usage that was already flagged by the strict-length, discussed above.
• No changes in Definitely Typed.
• No changes in internal MS projects.
• A few tests changes to assert that push and pop do not work on tuples.

Given that the total impact of this change is 3 good breaks (firebase, leaflet and highcharts), plus incorrect array syntax (9), I think that it is small enough to ship without a flag.

[sandersn]

We had one more meeting, and decided to ship this PR without a flag and without TupleBase. Shipping without a flag allows everybody to get the better checking with no work, and more easily unlocks future features based on fixed-length tuples. TupleBase is a nice idea in theory, but it's too cute in relying on the specifics of never assignability, and we suspect it will get us in trouble later.

[sandersn]

Thanks @tycho01!

[mhegazy]

@sandersn please add a note about this change in the breaking change section for TS 2.7.

We need also some guidance for the firebase use case

[mightyiam]

Hooray!

[Igorbek]

@tycho01 @sandersn you are the best! Thank you! @sandersn now this should unblock #5453, right? :)

[KiaraGrouwstra]

Thanks for the merge! At this rate I may get the motivation to finish those last few PRs too. :)

[michaeljota]

This should be added to the January release notes roadmap.

[sandersn]

@michaeljota I added it to the roadmap.