allow zero-valent tuple type

[zpdDG4gta8XKpMCd]

the {} type is allowed, while [] is not allowed, which is a sad news because i was planning to use it as a unit type distinct from null and undefined which have their own meaning already

consider allowing the empty tuple type

[DanielRosenwasser]

What exactly is the structural distinction between an empty tuple and undefined[] or never[]?

[zpdDG4gta8XKpMCd]

the length property that is always 0, no push, shift, unshift, pop, slice, splice operations, no index signature

[zpdDG4gta8XKpMCd]

@chicoxyzzy [] to [a] is what 0 is to 1, an identity type if you will: [] + [a] = [a], [a] + [] = [a]

https://homotopytypetheory.org/2011/04/18/whats-special-about-identity-types/

still confused?

[chicoxyzzy]

@Aleksey-Bykov TBH I don't understand the use case for such unit type.

[chicoxyzzy]

also {} is not unit type and it behaves similarly []

[zpdDG4gta8XKpMCd]

TBH I don't understand the use case for such unit type.

as i said it could have been yet another unit type in addition to null and undefined

also {} is not unit type and it behaves similarly []

{} is a valid type in TS and [] is gives an error, not sure what you are talking about

const values : [] = [];

[chicoxyzzy]

If [] will ever exist it should be an alias to any[] similarly to how {} is an alias to { [propName: string]: any }

[zpdDG4gta8XKpMCd]

any[] implies you can add elements to it:

const values: any[] = [];
values.push(1);

whereas [] is meant to be empty, that's the difference

const values: []= []; // hypothetical situation
values.push(1); // `push` method is not defined on `[]`

[chicoxyzzy]

In that way [] will behave differently to {} which doesn't hide any object prototype methods so that is counterintuitive

[zpdDG4gta8XKpMCd]

well it was never said that [] should behave anything like {} in the first place, not sure why we are trying to compare them

{} which doesn't hide any object prototype methods so that is counterintuitive

does the official TS guideline look counterintuitive to you? yet you can find ReadOnlyArray there which hides its prototype methods, riddle me that:

https://www.typescriptlang.org/docs/handbook/interfaces.html

[chicoxyzzy]

The counterintuitive part is that [] and {} behaviour will be different in your proposal. Readonly types indicate their behaviour explicitly and that's ok.

[chicoxyzzy]

Also as you mentioned you can declare your array unit as

const arrayUnit: ReadonlyArray<any> = [];

[zpdDG4gta8XKpMCd]

again, i don't care what {} is, it's outside of this topic (as far as i can tell), whatever behaviour it has it should be kept intact

here i was trying to talk about a different type which i called [], and the proposition for this type states that it possesses some unique properties yet very similar to ReadOnlyArray (except for the index signature and length property) which has been around since cac3a32

Also as you mentioned you can declare your array unit

no, i cannot declare it like that because i need it to be nonassignable from ReadOnlyArray<any>

[zpdDG4gta8XKpMCd]

and this is why:

const values: ReadOnlyArray<number> = [1, 2, 3];
let empty: [] = [];
empty = values; //<-- if ReadOnlyArray<a> is assignable, then the whole idea of having a type for an  EMPTY tuple doesn't make sense

[chicoxyzzy]

const empty: ReadonlyArray<any> = [];

empty.push(0);     // error
empty = [1, 2, 3]; // error