Naming of TypeScript's union and intersection types

I can't understand the logic behind the terms union types and intersection types in TypeScript.

Pragmatically, if the properties of different types are sets of properties, if I combine them with the & operator, the resulting type will be the union of the of those sets. Following that logic, I would expect types like this to be called union types. If I combine them with |, I can only use the common properties of them, the intersection of the sets.

Wikipedia seems to back that logic: > The power set (set of all subsets) of any given nonempty set S forms a Boolean algebra, an algebra of sets, with the two operations ∨ := ∪ (union) and ∧ := ∩ (intersection).

However, according to typescriptlang.org, it's exactly the opposite: & is used to produce intersection types and | is used for union types.

I'm sure there is another way of looking at it, but I cannot figure it out.

Here's another way to think about it. Consider four sets: Blue things, red things, big things, and small things.

If you intersect the set of all blue things and all small things, you end up with the union of the properties -- everything in the set has both the blue property and the small property.

But if you took the union of blue small things and red small things, only the smallness property is universal in the resulting set. Intersecting "blue small" with "red small" produces "small".

In other words, taking the union of the domain of values produces an intersected set of properties, and vice versa.

In image form:

The type A | B refers to objects which are either A or B. In other words, values of such type are drawn from the union of values for A and values for B.

The type A & B refers to objects which are both A and B. In other words, values of such type are drawn from the intersection of values for A and values for B.

The naming and semantics are identical in other languages such as C++.

The confusion here probably stems from how we imagine the sets, namely, thinking of the intersection/union as involving the members of types as opposed to the types themselves. I put together a graphic that hopefully clarifies the concept:

You must not think of types as sets of object properties in this case. We can avoid the confusion about how union and intersection types work by looking at scalar variables and their sets of permissible values (instead of objects):

type A = 1 | 2
type B = 2 | 3
type I = A & B
type U = A | B

let a: A
let b: B
let i: I
let u: U

a = 1
a = 2
a = 3 // <- error

b = 1 // <- error
b = 2
b = 3

i = 1 // <- error
i = 2
i = 3 // <- error

u = 1
u = 2
u = 3

Here the terms "union" and "intersection" correspond exactly to the set theory terms when applied to the sets of permissible values.

Applying the notion of permissible values (instances) to object types is a bit trickier (because the set theory analogy doesn't hold well):

type A = {
  x: number
  y: number
}

type B = {
  y: number
  z: number
}

type I = A & B
type U = A | B

• A variable of type A can hold object instances with properties x and y (and no other properties).
• A variable of type B can hold object instances with properties y and z (and no other properties).
• In set theory the intersection of the two sets of object intances above is empty. However, a variable of intersection type I can hold objects with the properties of type A AND those of type B (i.e. x, y, and z; hence the & symbol) which corresponds to the union of properties of the two types (hence the confusion).
• In set theory the union of the two sets of object intances above does not include objects with all three properties. However, a variable of union type U can hold objects with the properties of type A OR those of type B (logical OR, not XOR, i.e. x and y, y and z, or x, y, and z; hence the | symbol) which implies that the intersection of properties of the two types (y in our example) is guaranteed to be present (hence the confusion).

let i: I
let u: U

i = { x: 1, y: 2 };         // <- error
i = { y: 2, z: 3 };         // <- error
i = { x: 1, y: 2, z: 3 };

u = { x: 1, y: 2 };
u = { y: 2, z: 3 };
u = { x: 1, y: 2, z: 3 };

I also had the same question and couldn't understand how could it be seen in the opposite way. After reading the answers, I think I could explain it in the linguistic aspect providing different meanings of the two words and giving a room for the opposite naming approaches.

Compare the following meanings of word intersect:

>The orbit of this comet intersects the orbit of the Earth.

In this sentence intersect means to cross at a point or set of points. Think of two things having something common (e.g. a point), and otherwise different. That's what is called intersection in math and SQL.

> We need to pinpoint the place where maximum achievable conservation intersects with the highest potential financial return.

Here intersect means to come together and have an effect on each other, like two things becoming components of one new cool thing. That's the meaning of the word in TypeScript.

In a similar way you can think of union as an act of joining different things together in a loose sense - that is the meaning of union in math and SQL; but it can mean not just joining but joining together with a common interest or purpose which corresponds to the meaning of union in TypeScript.

Inspired (don't ask me why) by different translations of intersect into Russian: пересекать (also to cross) and скрещивать (also to crossbreed).

They just updated the documentation the other day, and now it provides a clarifying description with a simple example:

>It might be confusing that a union of types appears to have the intersection of those types’ properties. This is not an accident - the name union comes from type theory. The union number | string is composed by taking the union of the values from each type. Notice that given two sets with corresponding facts about each set, only the intersection of those facts applies to the union of the sets themselves. For example, if we had a room of tall people wearing hats, and another room of Spanish speakers wearing hats, after combining those rooms, the only thing we know about every person is that they must be wearing a hat.

https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types

type Head = {
  skin: string, 
  bones: string, 
  nouse: number, 
  eyes: number, 
  ears: number 
}

type Body = {
  skin: string, 
  bones: string, 
  arms: number, 
  foots: number
}

type Frankenstein = Head | Body

let frank: Frankenstein

`1 rule (only Head)`

frank = {skin: 'green', bones: 'skull', nouse: 1, eyes: 2, ears: 2}

`2 rule (only Body)`

frank = {skin: 'gray', bones: 'skeleton', arms: 2, foots: 2}

`3 rule (Body and Head all together)`
 
frank = {
  skin: 'green', 
  bones: 'skull', 
  nouse: 1, 
  eyes: 2, 
  ears: 2, 
  arms: 2, 
  foots: 2
}

`4 rule (Frank without arms or foots or ears or ...)`

frank = {
  skin: 'green', 
  bones: 'skull', 
  nouse: 1, 
  eyes: 2, 
  ears: 2,
  foots: 2
 }

frank = {
  skin: 'green', 
  bones: 'skull', 
  nouse: 1, 
  eyes: 2, 
  ears: 2, 
  arms: 2
}

frank = {
  skin: 'green',
  bones: 'skull',
  nouse: 1,
  eyes: 2,
  arms: 2, 
  foots: 2
}

`-1 rule (he can't exist without general parts)`

frank = {
  bones: 'skull',
  nouse: 1,
  eyes: 2,
  ears: 2,
  foots: 2} //error

frank = {
  skin: 'green',
  nouse: 1, 
  eyes: 2,
  ears: 2,
  arms: 2} //error

`-2 rule (and the MOST NOTABLY he can not exist without full kit of one of 
his parts, why - ask his best friend - TypeScript)`

frank = {
  skin: 'green',
  bones: 'skull',
  eyes: 2,
  ears: 2,
  foots: 2} //error

frank = {
  skin: 'green',
  bones: 'skull',
  nouse: 1,
  eyes: 2,
  arms: 2
} //error