Primitive intersections. Why is this allowed?

[electricessence]

TS Version
Currently using 2.2dev for 1121

Code

type Primitive = string | number | boolean;
type PrimitiveIntersection = string & number & boolean;

Expected behavior:
The compiler should at least warn the coder that this is invalid. I know it would be hard to track in some cases, but it seems this blatant declaration shouldn't be allowed.

Actual behavior:
No warning occurs.

[DanielRosenwasser]

The question has always been where to error on these things.

declare function intersect<T, U>(x: T, y: U): T & U;

intersect(10, "hello");

When intersect is resolved, the result creates a new intersection type. But TypeScript never errors on the creation of a type (at least internally).

Instead, you'd have to do a pre-check on the input types or a post-check on the produced type to see whether the types will have colliding primitives, or if any of the properties of the produced type will have colliding types.

[DanielRosenwasser]

Additionally, I'll note that while it's not necessarily correct, people have taken advantage of this behavior to enforce certain patterns.

type Feet = number & "feet";

[bcherny]

@DanielRosenwasser Maybe I'm dense, but what does that code accomplish?

[electricessence]

@bcherny I think he really means that it has to be a string that starts with a number and ends with "feet"? :|

[DanielRosenwasser]

@bcherny

Additionally, I'll note that while it's not necessarily correct,

Basically you can write cute stuff like this:

type Feet = number & "feet";
type Inches = number & "inches"

function feet(x: number): Feet {
    return x as Feet;
}

function addFeet(a: Feet, b: Feet) {
    return (a + b) as Feet;
}

function feetToInches(x: Feet) {
    return (x * 12) as Inches
}

let a = feet(10);
let b = feet(20)
addFeet(a, b); //okay

addFeet(10, 20); // error
addFeet(a, feetToInches(b)); // error

Try it in the playground.

[bcherny]

Woah, that is cool. But it seems so wrong. number & "feet" seems like nonsense to me..

[DanielRosenwasser]

@bcherny we know - see the design notes from #6735 (about type Path = string & { __somePathThing: void };) 😄

[bcherny]

@DanielRosenwasser Interesting discussion. It seems like what you want is "is type T, but not a subtype of or alias to T". I'm not sure what languages you could look at for inspiration here, but in Scala you could express something like it via negation types, though a bit clunky:

type JustFeet = Feet & Not[>:Feet] & Not[<:Feet]
def addFeet(a: JustFeet, b: JustFeet): Feet = a + b

In TS, maybe something like this would work, with : as the "is type T, but not a subtype of or alias to T" operator:

function addFeet(a: :Feet, b: :Feet): Feet {
  return a + b
}

type Feet = number

let a: Feet = 1
let b: Feet = 2

addFeet(a, b) // 3
addFeet(a, 2) // Error

This would open the door for Scala-style "is subtype of" <: operator and "is supertype of" >: operator.