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

The nomenclature for intersection types and union types is confusing. #18383

Closed
rzvc opened this issue Sep 11, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@rzvc
Copy link

commented Sep 11, 2017

Hey guys,

This is bothering me whenever I go through the documentation.

Current naming:

  1. TypeA & TypeB - intersection type.
  2. TypeA | TypeB - union type.

Maybe I'm not seeing some subtlety, but the & type operator has nothing to do with intersection and while the | operator creates a type that can be considered a type guarded union (with the meaning of union taken from C++), the result of a & operator has much more resemblance to that type of union, while the result of the | operator is basically an intersection.

That said, I like the idea of a type guarded union and I'm sort of ok with | being named a union operator, but at least the & operator should be renamed to something else, because it's not an intersection.

The way I see it there are two options:

  1. Keep | operator named a union operator and rename & to something else (ex: merge operator / merged types).
  2. Give up on the C++ meaning and rename | types to intersection types, because that's what the resulting type is and rename & types to union types.

The bottom line is that the current nomenclature is confusing, because & is not an intersection and | it sort of is.

@j-oliveras

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2017

I think, you must read this as:
TypeA & TypeB (intersection type): the resultant type is TypeA AND TypeB.
TypeA | TypeB - (union type): the resultant type is TypeA OR TypeB.

I don't think this names are related to C++.

@ahejlsberg

This comment has been minimized.

@rzvc

This comment has been minimized.

Copy link
Author

commented Sep 11, 2017

@j-oliveras, the way in which is related to C++ is through the use of the union type. Granted, it's only a loose connection, but you can use unions in C++ almost exactly like you use them in typescript. If this is not why they're being called unions, then that's more reason not to keep this naming convention.

@ahejlsberg, unfortunately there's no correct answer there (as of now).
Given A = [1, 2, 3] and B = [3, 4], the intersection between them is [3] not [1, 2, 3, 4]. [1, 2, 3, 4] is the union between the two. This is how math works, yet in typescript they have the exact opposite effect. Intersection types result in the union between two types and union types result in the intersection between two types.

@ahejlsberg

This comment has been minimized.

Copy link
Member

commented Sep 11, 2017

@rzvc The key thing to understand is that union and intersection refers to the set of possible values of a type. For example, A | B represents a type whose set of possible values is the union of the sets of possible values of A and B. This nomenclature is consistent with type theory and numerous functional programming languages that have similiar concepts.

@mhegazy mhegazy added the Question label Sep 11, 2017

@rzvc

This comment has been minimized.

Copy link
Author

commented Sep 11, 2017

@ahejlsberg Thanks. Than I guess type theory got its nomenclature wrong and this is the wrong tree to bark at.

Also a quick answer to your reply. While I don't have that big of a problem with A | B being called a union, because I can warp the meaning of the term in my head to fit this definition. I do have a lot of trouble with A & B being called an intersection. If the theory says that's what it should be called, than the theory is wrong. It simply goes against reason to sustain that the intersection between two things is both things in their entirety.

That being said, if it's wanted for typescript to stay true to the theory, then maybe it can just keep the union types and rename the intersection types to something else, because people have a very different (and correct) idea about what an intersection and a union is, and it isn't what the documentation says it is. Going against the intuition of the users is never ideal, especially when it's done simply because someone got the naming convention wrong.

Edit: There's a lot to say about the type operators themselves too, where | means AND and & means OR, but that's a different discussion.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Sep 11, 2017

people have a very different (and correct) idea about what an intersection and a union is, and it isn't what the documentation says it is

This doesn't match our experience. The very first users who wanted union types called them union types; flow calls them union types (and had them first) and also calls intersection types intersection types, etc.. It's certainly not going to be less confusing to suddenly have a new synonym that sounds like it might be a new kind of thing but isn't.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.