Why is the `&` operator called an intersection?

[popham]

I had to check out the tests to figure out what the intersection operator does. My intuition says that an intersection of two types should yield a type that is of equal or greater strength than both operands. The & operator smells more like a sum to me. I guess it doesn't matter, but a {x:number}&{y:number} example in the docs would have saved me some aggravation.

It's probably too late, but I would expect an intersection operator to provide (string | number) \cap (string | SomeClass) = string and {x: number | string, y: string} \cap {x: string, y: number} = {x: string}. I could use this intersection operator as a workaround (type Null = ?string \cap ?number), but it could be useless in practice. I mention the alternative in case it justifies deprecating the & symbol in favor of a + symbol. Then an intersection (\cap or something else) could take the & symbol someday.

[avikchaudhuri]

@popham & indeed means intersection in the sense you describe, but our support for intersection types right now is pretty hacky. I'm working on making them better.

To elaborate on your intuition: if you think of a type as describing a set of values, an intersection type describes an intersection of sets of values. The type { x: number } represents the set of objects that have at least property x: number (could have more, via structural subtyping), and similarly, { y: number} the set of objects having at least y: number. So their intersection is the set of objects that have at least x: number and y: number, which is described by the type { x: number, y: number }. This is a common source of mindfuck, but makes sense when you realize that "adding more properties" actually makes an object type more restrictive (i.e., "smaller").

[popham]

Ah. Thanks for the explanation. I parse your explanation to the following:

{x: number} => {js objects s.t. there exists a numeric property x}
{y: number} => {js objects s.t. there exists a numeric property y}
{x: number} & {y: number} =>
    {js objects s.t. there exists both numeric properties x and y} = {x: number, y: number}

[strangemonad]

I know this issue is old but I was just running through the math in my head to convince myself of the same thing so I thought I’d provide an alternative explanation while it’s fresh in my head since others might search old bugs for explanations. (I’ll try and come up with a nicer explanation for the docs).

The set of values interpretation is correct but didn’t help my brain grasp why the intersecion type has all properties (my initially wrong assupmtion was that shouldn’t it be a restriction of the properties).

The alternative, order-theoretic, interpretation is to think of the subtyping relation that must hold. Assuming from above:

type A = {x: number}
type B = {y: number}
type C = A & B

Then it must be true that C <: A and C <: B. In this case C must be a record type with at least the properties {x : number, y:number}. I.e. an intersection of records is satisfied by a record that has at least the union of the source record’s feilds. Put another way, a value of type C could be given to someone that just needs a value of type A (or B) and the code would work just fine.

This agrees with the concept of width subtyping explained well here https://flow.org/en/docs/lang/width-subtyping/ and https://en.m.wikipedia.org/wiki/Subtyping