Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow zero-valent tuple type #13239

Closed
zpdDG4gta8XKpMCd opened this issue Jan 1, 2017 · 19 comments
Closed

allow zero-valent tuple type #13239

zpdDG4gta8XKpMCd opened this issue Jan 1, 2017 · 19 comments

Comments

@zpdDG4gta8XKpMCd
Copy link

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
Copy link
Member

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

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Jan 2, 2017

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

@zpdDG4gta8XKpMCd
Copy link
Author

@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
Copy link
Contributor

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

@chicoxyzzy
Copy link
Contributor

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

@zpdDG4gta8XKpMCd
Copy link
Author

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 : [] = [];

image

@chicoxyzzy
Copy link
Contributor

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

@zpdDG4gta8XKpMCd
Copy link
Author

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
Copy link
Contributor

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

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Jan 2, 2017

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

image

@chicoxyzzy
Copy link
Contributor

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

@chicoxyzzy
Copy link
Contributor

chicoxyzzy commented Jan 2, 2017

Also as you mentioned you can declare your array unit as

const arrayUnit: ReadonlyArray<any> = [];

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Jan 2, 2017

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
Copy link
Author

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
Copy link
Contributor

chicoxyzzy commented Jan 2, 2017

const empty: ReadonlyArray<any> = [];

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

@zpdDG4gta8XKpMCd
Copy link
Author

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 late

@chicoxyzzy
Copy link
Contributor

This is strange when you assign non-empty array to a constant variable named empty. Can you provide an example?

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Jan 2, 2017

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 nonEmpty to empty and forgot to fix the declaration

// after renaming
const empty : ReadOnlyArray<any> = [1, 2, 3]; // no problem, although doesn't make sense

@zpdDG4gta8XKpMCd
Copy link
Author

closed in favor of #13126

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants