GeezerVison

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

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?

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.

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.

@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.

Update: should be good now, ready for feedback.

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

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

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

• 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.

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.

Thanks @tycho01!

Nathan Shively-Sanders (@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

Hooray!

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

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

This should be added to the January release notes roadmap.

Michael De Abreu (@michaeljota) I added it to the roadmap.