Repository navigation
allow zero-valent tuple type #13239
Description
Activity
What exactly is the structural distinction between an empty tuple and
undefined[]ornever[]?the
lengthproperty that is always0, nopush,shift,unshift,pop,slice,spliceoperations, no index signatureSergey Rubanov (@chicoxyzzy)
[]to[a]is what0is to1, an identity type if you will:[] + [a] = [a],[a] + [] = [a]https://homotopytypetheory.org/2011/04/18/whats-special-about-identity-types/
still confused?
Aleksey-Bykov TBH I don't understand the use case for such unit type.
also
{}is not unit type and it behaves similarly[]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
nullandundefinedalso {} 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 aboutconst values : [] = [];
If
[]will ever exist it should be an alias toany[]similarly to how{}is an alias to{ [propName: string]: any }any[]implies you can add elements to it:const values: any[] = []; values.push(1);whereas
[]is meant to be empty, that's the differenceconst values: []= []; // hypothetical situation values.push(1); // `push` method is not defined on `[]`In that way
[]will behave differently to{}which doesn't hide any object prototype methods so that is counterintuitivewell 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
ReadOnlyArraythere which hides its prototype methods, riddle me that:https://www.typescriptlang.org/docs/handbook/interfaces.html
The counterintuitive part is that
[]and{}behaviour will be different in your proposal. Readonly types indicate their behaviour explicitly and that's ok.Also as you mentioned you can declare your array unit as
const arrayUnit: ReadonlyArray<any> = [];
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 intacthere 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 toReadOnlyArray(except for the index signature andlengthproperty) which has been around since cac3a32Also 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>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 senseconst empty: ReadonlyArray<any> = []; empty.push(0); // error empty = [1, 2, 3]; // error
const empty: ReadonlyArray<any> = [1, 2, 3]; empty.push(0); // error, but who cares it already has [1, 2, 3] instead of being empty empty = [1, 2, 3]; // error, again too lateThis is strange when you assign non-empty array to a constant variable named
empty. Can you provide an example?easily
- you made a mistake
const values : ReadOnlyArray<any> = Math.random() > 0.5 ? [1, 2, 3] : []; if (values.length) { // <-- accidently flipped condition const empty : ReadOnlyArray<any> = values; }- renaming
// before const nonEmpty : ReadOnlyArray<any> = [1, 2, 3];someone renamed
nonEmptytoemptyand forgot to fix the declaration// after renaming const empty : ReadOnlyArray<any> = [1, 2, 3]; // no problem, although doesn't make senseclosed in favor of #13126
- locked and limited conversation to collaborators
on Jun 19, 2018
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 fromnullandundefinedwhich have their own meaning alreadyconsider allowing the empty tuple type