Empty tuple type now meaningful (at least, in unions)

[krryan]

I have a situation where the only valid states for a property are [], [A], or [A, B, B], so I would like to define that property as [] | [A] | [A, B, B]. But this gives the error "A tuple element list cannot be empty," and indeed I see that there were a few prior issues relating to the compiler having (incorrectly) allowed it in the past. It seems to me that now, between overloading and unions, this type is useful. Also useful in a typeguard: isEmpty<A>(values: A[]): values is [] { return values.length === 0; }

I suppose the most difficult part of it would be actually tracking that a given array is empty, so that it could be matched against that definition.

Per the checklist, the grammar is simple enough, [] in type positions, shouldn't have any issues with respect to JavaScript. I don't foresee any semantic issues except the above bit about actually recognizing empty arrays as such. The emit isn't affected at all, and compatibility shouldn't be an issue. I'm not rightly sure about the concerns raised in the Other section.

[RyanCavanaugh]

Approved, accepting PRs. The type [] should have an index signature type of never, and needs to be assignable from the literal [] (in both strictNullChecks on and off)

[KiaraGrouwstra]

From @Aleksey-Bykov at his #13239 on what distinguishes tuples (like this 0-ary one):

no push, shift, unshift, pop, slice, splice operations

[] [...] possesses some unique properties yet very similar to ReadOnlyArray (except for the index signature and length property)

the length property that is always 0

no index signature

To summarize compared to ReadOnlyArray:

• same: no mutating methods
• more granular: known length
• proposed difference: no index signature

My instinct had been to have a Tuple sub-typing ReadOnlyArray to specify the known length. This implies retaining the index (yielding just a union of the tuple's constituent types), such as to keep e.g. [number] assignable to ReadOnlyArray<number>, and just having it return never for empty tuple as stated by Ryan. Would you mind commenting on your request to keep the index out, @Aleksey-Bykov?

Interestingly, specifying length may address #6229.

[KiaraGrouwstra]

@gcnew at #17767 (comment):

I think it would have been best if tuples behaved like object with their indices as keys. All the normal object rules should be in effect. For example, the indexing type variable should be a keyof of the tuple, or the tuple should be intersected with an indexer to provide a default value.

// ['syntax', true] => { 0: 'syntax', 1: true }
type Tup = ['syntax', true]
type T1<I> = Tup[I] // error
type T2<I extends number> = Tup[I] // error
type T2<I extends keyof Tup> = Tup[I] // OK
type T2<I extends number> = (Tup & { [k: number]: undefined })[I] // OK

On a side note, I don't think tuples should be a subclass of Array. In the general sense, they are not arrays, just values packed together. That's further exacerbated by the fact that tuples are heterogeneous in the majority of cases.

Question based on that, also to @Aleksey-Bykov: would it not be unfortunate if dropping the index would mean tuples would even no longer match ArrayLike? It would be possible to refer to tuples in general if they had their own interface, but it would seem to get harder to refer to any array (be it homogeneous or tuple) this way.

[gcnew]

@tycho01
If tuples have a length property, they will be assignable to ArrayLike.

type Tuple2<A, B> = { 0: A, 1: B, length: 2 }

declare function mkTuple2<A, B>(a: A, b: B): Tuple2<A, B>;
declare function useArrayLike<T>(x: ArrayLike<T>): void;

useArrayLike(mkTuple2(1, 'hello'));

On the other hand, an exact length type will make Tuple3 not assignable to Tuple2, which depending on the use-case might be a good or a bad thing.

To be honest, I haven't thought over all consequences and edge cases.

[KiaraGrouwstra]

If tuples have a length property, they will be assignable to ArrayLike.

And here I thought that needed an index. Pretty cool!

On the other hand, an exact length type will make Tuple3 not assignable to Tuple2, which depending on the use-case might be a good or a bad thing.

Right. So the consequences of this one we know at least (#17765, see changed test files). Result: not so bad! Wait a second, it was that other PR (#17785) I tested over the whole project. Whoops.

[KiaraGrouwstra]

To put discussions on a first-class Tuple interface (as a ReadonlyArray ripoff without number index) in further context, I've added an experimental branch for this here.
I tried for a bit, but am currently getting assignability errors like this one:

1430             addRange(result, <Symbol[]>checker.getSymbolsOfParameterPropertyDeclaration(<ParameterDeclaration>symbol.valueDeclaration, symbol.name));
src/services/findAllReferences.ts(1430,30): error TS2352: Type '[Symbol, Symbol]' cannot be converted to type 'Symbol[]'.
  Property 'push' is missing in type '[Symbol, Symbol]'.

Edit: note that this issue also occurs if you even just tie tuples to ReadonlyArray instead of Array.