Future proof union to intersection type conversion

[zenorbi]

Search Terms

union to intersection, type merge

Suggestion

I'd like to either standardize (meaning documented behavior) or have a less hacky (future proof) way of transforming union types to intersections.

Use Cases

The most common use case I can think of is a basic action system where each action has some kind of input data it can work with to determine its disabled status. An actionGroup which packs multiple actions into one updater function needs to request the right input data type which is compatible to all of its actions.

While it's possible in the current version of typescript, it feels like a hack.

Examples

A more presentable form by describing a car dashboard:

interface Gauge<T> {
    display(data: T): void;
}

class SpeedGauge implements Gauge<{ speed: number; }> {
    display(data: { speed: number; }) {
    }
}

class TempGauge implements Gauge<{ temperature: number; }> {
    display(data: { temperature: number; }) {
    }
}

class RevGauge implements Gauge<{ rev: number; }> {
    display(data: { rev: number; }) {
    }
}

type ExtractGaugeType<T> = T extends Gauge<infer U> ? U : never;

// evil magic by jcalz https://stackoverflow.com/a/50375286
// I would like to future proof or have a better version of this
type UnionToIntersection<U> = (U extends any ? (k: U) => void : never) extends ((k: infer I) => void) ? I : never;

class Dashboard<T extends Gauge<unknown>> {
    constructor(public gauges: T[]) {
    }

    display(data: UnionToIntersection<ExtractGaugeType<T>>) {
        this.gauges.forEach((g) => g.display(data));
    }
}

const myDashboard = new Dashboard([new SpeedGauge(), new TempGauge(), new RevGauge()]);

/*
the type is: { rev: number; } & { speed: number; } & { temperature: number; }
*/
myDashboard.display({ // Ok
    speed: 50,
    rev: 2000,
    temperature: 85
});

myDashboard.display({ // Error: property "rev" is missing
    speed: 50,
    temperature: 85
});

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[AnyhowStep]

Damn. I wish I knew about this trick sooner!
I've been using tuples, conditional types, and copy-pasting code to get unions to become intersections!

[jack-williams]

If negated types are merged I think you can do this:

type UnionToInterWorker<T> = not (T extends T ? not T : never);
type UnionToInter<T> = [T] extends [never] ? never : UnionToInterWorker<T>;

Though I think we need to be careful about using complex type operations as a sledgehammer. The more complex the type operators the greater that disparity between our code and types, and we end up having to rely on casts to get things through.

First, IMO, is to look at what we are trying to solve (semantically, not mechanically) and try and get the type system to work with us. With @weswigham's work on union signatures I can get your example to type-check with the following:

class Dashboard<T extends Gauge<unknown>> {
    constructor(public gauges: T[]) {
        
    }

    display: T["display"] = (data) => {        
        this.gauges.forEach((g) => g.display(data));
    }
}

myDashboard.display({ // Ok
    speed: 50,
    rev: 2000,
    temperature: 85
});

/**
 * Argument of type '{ speed: number; temperature: number; }' is not assignable to parameter of type '{ speed: number; } & { rev: number; } & { temperature: number; }'.
 * Property 'rev' is missing in type '{ speed: number; temperature: number; }' but required in type '{ rev: number; }'. [2345]
 */
myDashboard.display({
    speed: 50,
    temperature: 85
});

Not only is this clearer, but it precisely captures intent. To me, at least, this is exactly the kind of solution TypeScript should be encouraging, and I think adding a load of complex type manipulation as part of the standard would guide people in the wrong direction.

[AnyhowStep]

What about this use case (adapted from a personal project),

function and<ArrT extends AnonymousTypedExpr<boolean>[]> (...arr : ArrT) : Expr<{
    usedRef : UnionToIntersection<ArrT[number]["usedRef"]>,
    value : boolean,
}>;

usedRef' is a type such that I can get away with using the & operator instead of using complicated type merging operations.

But without the magical UnionToIntersection, I'm left with either copy pasting and creating overloads for each number of arguments, or using conditional types for each length of a tuple

[zenorbi]

@jack-williams I can't seem to make your example work. Using TypeScript@3.2.4 and it tells me

Dashboard<SpeedGauge | TempGauge | RevGauge>.display: ((data: {
    speed: number;
}) => void) | ((data: {
    rev: number;
}) => void) | ((data: {
    temperature: number;
}) => void)

and

[ts] Cannot invoke an expression whose type lacks a call signature. Type '((data: { speed: number; }) => void) | ((data: { rev: number; }) => void) | ((data: { temperature: number; }) => void)' has no compatible call signatures. [2349]

myDashboard.display({
    speed: 50,
    rev: 2000,
    temperature: 85
});

[jack-williams]

@zenorbi The feature is set for 3.3. Release notes.

[zenorbi]

@jack-williams Oh, this is a nice surprise. And I also agree with you that your T["display"] solution is much closer to what to code actually does. Thank you for your help.

[jack-williams]

@zenorbi

No problem! Yes, it is a really nice addition to the language.

I will just add the caveat that I have nothing to do with TS team, so please don't take my view as anything more than an outsider perspective.

I do think there is a discussion to be had around what type operators are needed in the language: a union to intersection operator might be one of them. If the problems people face can be solved by being smarter with existing types then I think that is better, but sometimes things really do need new features.

Unless your issue was really about that specific use case, then it might be worth leaving the issue open and getting the POV from the team and other users.

[RyanCavanaugh]

I don't think we can commit to any particular "black magic" working in the future, nor offer a built-in operation for it unless more common use cases arise.

[weswigham]

The negated type method is likely pretty solid, though. It falls out from a core identity of the type, so once merged, it's highly unlikely to cease to work. IMO, it'll be more of a constant than the variance-reliant inversion you can find in the wild today.