Proposal: Add an "exclusive or" (^) operator

Question

Proposal: Add an "exclusive or" (^) operator

mohsen1 opened this issue 7 years ago · comments

Based on this comment TypeScript does not allow exclusive union types.

I'm proposing a logical or operator similar to union (|) or intersection (&) operators that allows defining types that are one or another.

Code

type Person = { name: string; } ^ { firstname: string; lastname: string; };

const p1: Person = { name: "Foo" };
const p2: Person = { firstname: "Foo", lastname: "Bar" } ;

const bad1: Person = { name: "Foo", lastname: "Bar" }
                                    ~~~~~~~~~~~~~~~   Type Person can not have name and firstname together 
const bad2: Person = { lastname: "Bar", name: "Foo" }                                            
                                        ~~~~~~~~~~~   Type Person can not have lastname and name together

For literal and primitive types it should behave like union type:

// These are the same 
type stringOrNumber = string | number;
type stringORNumber = string ^ number;

Mohamed Hegazy · Answer 1 · Thu Feb 16 2017 04:31:29 GMT+0800 (China Standard Time)

The issue is there are no exact/final types in TS. all types are open ended. so this is allowed from an assignable perspective:

var p1: {name: string };
var p2 =  {name:"n", firstName: "f", lastName: "l"};
p1 = p2;  // OK

A type is assignable to a union type, iff it is assignable to one of the constituents. so even with the exclusive union, open types would allow that check to pass.

Another feature that TS has is flagging "unknown" properties. This only applies to object literals, that happen to have a contextual type. e.g.:

var p: {name: string} = { name: "n", another: "f" }; // Error `another` is not a known property

This check is simplified for union types, just to say it has to be a "known" property on the union in general, not for this constituent. The main issue here is how unions are compared, when we are comparing constituent types, we do not know if we should check for "unknown" properties, because it might be one of the other types.

If i am not mistaken, you are after this unknown property check in this case. I would say we are better off trying to change how this is handled for unions, rather than creating a new concept in the language that users need to understand.

Related discussion in #12997. Issue tracked by #12745

Mohsen Azimi · Answer 2 · Fri Feb 17 2017 02:29:46 GMT+0800 (China Standard Time)

#12745 will solve parts of this problem. But it won't have exclusive or logic because tagged unions are merging assignable types. For example:

interface A { foo: string; }
interface B { bar: string; }

type C = A | B;

const a: C = { foo: '' } // Wrongfully ✔ // Hopefully #12745 fixes this
const b: C = { bar: '' } // Wrongfully ✔ // Hopefully #12745 fixes this
const c: C = { foo: '', bar: '' } // ✔

What I'm suggesting is an exclusive or operator between two interfaces:

interface A { foo: string; }
interface B { bar: string; }

type C = A ^ B;

const a: C = { foo: '' } // ✔
const b: C = { bar: '' } // ✔
const c: C = { foo: '', bar: '' } // ❌

Mohamed Hegazy · Answer 3 · Fri Feb 17 2017 04:31:59 GMT+0800 (China Standard Time)

without exact types the new operator does not solve the issue, since { foo: '', bar: '' } is still a { foo: string; }

Manuel Rivera · Answer 4 · Sat Mar 11 2017 03:26:02 GMT+0800 (China Standard Time)

This would be really helpful, Allows better management in development time.

Ryan Cavanaugh · Answer 5 · Sat Mar 11 2017 05:00:33 GMT+0800 (China Standard Time)

Presumably the behavior here would be that

type A = { m: T } ^ { n : U };

is equivalent to

type A = { m: T, n: undefined } | { m: undefined, n : U };

Mohsen Azimi · Answer 6 · Sat Mar 11 2017 06:19:34 GMT+0800 (China Standard Time)

@RyanCavanaugh it makes it even easier to implement as de-sugar algorithm is so easy!

This operator is still a good idea since there are lots of cases where an API expect two or more completely different interfaces.

Adding undefined can pile up quickly:

type A = { m: T } ^ { n:  U } ^ { o: Q }

vs.

type A = 
    { m: T; n: undefined; o: undefined; } |
    { m: undefined; n: U; o: undefined; } |
    { m: undefined; n: undefined; o: Q; }

Ryan Cavanaugh · Answer 7 · Fri May 12 2017 04:31:42 GMT+0800 (China Standard Time)

Search terms so I can find this later: "mutually exclusive" "disjoint unions"

Matt Banz · Answer 8 · Sat Jun 03 2017 05:30:24 GMT+0800 (China Standard Time)

I'd like to add another use case for this feature. I'm currently using json-schema-to-typescript to generate TypeScript interfaces from JSON Schema. Currently the "oneOf" keyword is listed as not expressible in TypeScript. Having exclusive unions would then make it expressible.

Luke Scott · Answer 9 · Thu Nov 16 2017 07:50:12 GMT+0800 (China Standard Time)

With this example:

type A = { m: T } ^ { n:  U } ^ { o: Q }
// ->
type A = 
    { m: T; n: undefined; o: undefined; } |
    { m: undefined; n: U; o: undefined; } |
    { m: undefined; n: undefined; o: Q; }

This actually doesn't work:

// Assume T, U, and Q are string:
let a = { // <-- error
  m: ""
}

Because it expects:

// Assume T, U, and Q are string:
let a = {
  m: "",
  n: undefined, // <-- expects undefined value
  o: undefined,  // <-- expects undefined value
}

You have to define it like this:

type A = 
    { m: T; n?: undefined; o?: undefined; } |
    { m?: undefined; n: U; o?: undefined; } |
    { m?: undefined; n?: undefined; o: Q; }

But that allows you to put n: undefined on the object, which makes the key enumerable. So far I've found this works out better:

type A = 
    { m: T; n?: never; o?: never; } |
    { m?: never; n: U; o?: never; } |
    { m?: never; n?: never; o: Q; }

I wish there was an ^ operator. I've been bitten by thinking | was supposed to be an exclusive OR. Thinking about bitwise it makes sense. But I almost always want ^ instead of |.

Kevin Ryan · Answer 10 · Fri Mar 16 2018 02:57:39 GMT+0800 (China Standard Time)

I'm all for the ^ sugar, that's great.

But I also think TS needs to recognize and leverage mutually-exclusive union patterns, regardless of the sugar. For example, { kind: 'foo'; } | { kind: 'bar'; } is mutually exclusive because kind cannot possibly be 'foo' and 'bar' simultaneously. Likewise with literal number types. And naturally, { m: T; n?: never; } | { m?: never; n: U; } under discussion as a de-sugared { m: T; } ^ { n: U; } is mutually exclusive as well. None of these types is mutually exclusive because of any specific syntax, they just are exclusive by their very nature.

But TS doesn't recognize or leverage that fact as strongly as it could. For examples, #20375 and #21879 could benefit from recognizing mutually exclusive unions to allow for narrowing (that would not be safe with mutually inclusive unions). So I think this request should be more than just sugar. I would expect something like declare const test: { kind: 'foo'; } & { kind: 'bar'; } to result in test: never, but it doesn't, and TS will happily allow you to pass test to anything that's expecting a { kind: 'foo'; } or anything that's expecting a { kind: 'bar'; }.

Ryan Cavanaugh · Answer 11 · Fri Mar 16 2018 03:17:21 GMT+0800 (China Standard Time)

We already turn unit type contradictions ("foo" & "bar") into never during union/intersection type distribution.

Going further than that is somewhat dangerous because it means we'd produce never in a way that was fundamentally un-debuggable - imagine intersection two types and deep inside two uninteresting properties conflict and the whole thing collapses to never and you'd have no way to figure out why.

Also, sometimes you want to intersect two types in a way where you're using the part of it that isn't contradictory.

Kevin Ryan · Answer 12 · Fri Mar 16 2018 03:23:11 GMT+0800 (China Standard Time)

I agree with the debugging issue; having a way to investigate type inference would be really useful in general but I imagine that would be very difficult to offer.

But I still think never is the correct type for this case. Omit could be used, perhaps, to specify that you weren't interested in that bit that conflicts; certainly on our project, that would be an expectation that we'd have of our coders, to be explicit about something like that.

Finally, even if you really want to maintain { kind: 'foo'; } & { kind: 'bar'; }, test.kind should still have the type never. It currently has the type 'foo' & 'bar', which is, again, impossible.

Griffork · Answer 13 · Fri Mar 16 2018 14:35:19 GMT+0800 (China Standard Time)

It seems like this operator should result in closed types rather than open types like the union operator.

Mohsen Azimi · Answer 14 · Fri Mar 16 2018 15:41:25 GMT+0800 (China Standard Time)

I think I figured this out. By introducing a Without generic that forces all properties in an object to not present we can construct a working XOR generic:

FYI @isiahmeadows

type Without<T> = { [P in keyof T]?: undefined };
type XOR<T, U> = (Without<T> & U) | (Without<U> & T)

type NameOnly = { name: string };
type FirstAndLastName = { firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>

const p1: Person = { name: "Foo" };
const p2: Person = { firstname: "Foo", lastname: "Bar" } ;

const bad1: Person = { name: "Foo", lastname: "Bar" }
const bad2: Person = { lastname: "Bar", name: "Foo" }

Works in 2.7:

Sylvain Estevez · Answer 15 · Fri Mar 16 2018 19:19:07 GMT+0800 (China Standard Time)

@mohsen1 Hat off! 🎩

I've tried to play with your solution a bit, and so far I haven't been able to find a solution that allows common property names to remain in the resulting type. Below a simple example:

In the real life use cases I have for an exclusive OR type, objects generally have at least some properties in common.

I guess that joins the mutually exclusive concerns in the previous comments.

Geo · Answer 16 · Fri Mar 16 2018 21:58:35 GMT+0800 (China Standard Time)

@SylvainEstevez Maybe this way?

Sylvain Estevez · Answer 17 · Fri Mar 16 2018 22:51:34 GMT+0800 (China Standard Time)

@geovanisouza92 Yes that'd definitely work! Only issue is that it requires the Pizza and Sandwich types declaration to be split, which in real life would be pretty weird :/

Claudia Meadows · Answer 18 · Fri Mar 16 2018 23:26:51 GMT+0800 (China Standard Time)

@mohsen1 Do you need to include the intersection? I know yours is effectively the symmetric difference based on properties, but it seems people here were looking for something closer to a logical xor rather than a set-wise xor.

Mohsen Azimi · Answer 19 · Sat Mar 17 2018 00:10:04 GMT+0800 (China Standard Time)

I agree, we need to address shared properties too. I've made an Intersection generic that can get us some good result but it doesn't work for all cases

type Without<T> = { [P in keyof T]?: undefined };
type Intersection<T, U> = { [P in keyof (T | U)]: T[P] | U[P] };
type XOR<T, U> = Intersection<T,U> | ((Without<T> & U) | (Without<U> & T));

type NameOnly = { name: string; height: number; };
type FirstAndLastName = { firstname: string; lastname: string; height: number; }
type Person = XOR<NameOnly, FirstAndLastName>
type HeightOnly = Intersection<NameOnly, FirstAndLastName>

const h: HeightOnly = { height: 100 }
const p1: Person = { name: "Foo", height: 1.8 };
const p2: Person = { firstname: "Foo", lastname: "Bar", height: 2.0 } ;

const bad1: Person = { name: "Foo", lastname: "Bar" }
const bad2: Person = { lastname: "Bar", name: "Foo" }                                            
const bad3: Person = { name: "Foo", lastname: "Bar", height: 10 } // 😵

I'm confused why bad3 is a member of Person type?

EliSnow · Answer 20 · Sat Mar 17 2018 00:50:26 GMT+0800 (China Standard Time)

Using the upcoming TypeScript 2.8 Exclude type, what about:

type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (Without<T, U> & Required<U>) | (Without<U, T> & Required<T>)

type NameOnly = { is: "NameOnly", name: string };
type FirstAndLastName = { is: "FirstAndLastName", firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>;

let person: Person;

person = { is: "NameOnly", name: "Foo" };
person = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

Mohsen Azimi · Answer 21 · Sat Mar 17 2018 01:05:49 GMT+0800 (China Standard Time)

@EliSnow wow! Conditional Types were answer to every TypeScript problem, weren't they?

I think Required is not necessary there. It can break optional members of T and U

type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (Without<T, U> & U) | (Without<U, T> & T)

type NameOnly = { name: string; height: number; weight?: number; };
type FirstAndLastName = { firstName: string; lastName: string; height: number; }
type Person = XOR<NameOnly, FirstAndLastName>

const p1: Person = { name: "Foo", height: 1.8 };
const p2: Person = { name: "bar", height: 1.3, weight: 100 }
const p3: Person = { firstName: "Foo", lastName: "Bar", height: 2.0 } ;

const bad1: Person = { name: "Foo", lastName: "Bar" }
const bad2: Person = { lastName: "Bar"}
const bad3: Person = { height: 10 }
const bad4: Person = { name: "Foo", lastName: "Bar", height: 10 }

We ask for new operators and random fancy features and @ahejlsberg is like here is "conditional types" go build those things yourself! 😁

EliSnow · Answer 22 · Sat Mar 17 2018 01:13:22 GMT+0800 (China Standard Time)

A little more conditional types magic so it works with primitive types:

type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (T | U) extends object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U;

type NameOnly = { is: "NameOnly", name: string };
type FirstAndLastName = { is: "FirstAndLastName", firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>;
let person: Person;

person = { is: "NameOnly", name: "Foo" };
person = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

let stringOrNumber: XOR<string, number>;
stringOrNumber = 14;
stringOrNumber = "foo";

let primitiveOrObject: XOR<string, Person>;

primitiveOrObject= "foo";
primitiveOrObject= { is: "NameOnly", name: "Foo" };
primitiveOrObject= { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

Mohsen Azimi · Answer 23 · Sat Mar 17 2018 01:21:29 GMT+0800 (China Standard Time)

@EliSnow
Yup with primitives exclusiveness doesn't mean anything. Your latest iteration satisfy everything I asked in the original post.

Claudia Meadows · Answer 24 · Sat Mar 17 2018 15:01:28 GMT+0800 (China Standard Time)

@mohsen1 BTW, I beat you to it kind of already for the logical variant of the type.

Cyrille Tuzi · Answer 25 · Tue May 01 2018 03:29:56 GMT+0800 (China Standard Time)

#23777 is an example of why this feature would be very nice without complex workarounds, which can cause performance issues.

Zheeeng · Answer 26 · Thu Jun 14 2018 13:23:41 GMT+0800 (China Standard Time)

@mohsen1 There is a problem in type guarding after object spreading:

function foo(f: NameOnly) { }
function bar(b: FirstAndLastName) { }

function test(p: Person) {
    const rest = {...p}
    if ('name' in rest) {
        foo(rest)       // (1)
    } else {
        bar(rest)       // (2)
    }
}

(1) report error and the type of rest is:

const rest: { name?: never; weight?: never; firstName: string; lastName: string; height: number; } | { firstName?: never; lastName?: never; name: string; height: number; weight?: number; }

(2) works as expected and the type of rest is

const rest: { name?: never; weight?: never; firstName: string; lastName: string; height: number; }

Ryan Cavanaugh · Answer 27 · Wed Oct 10 2018 01:25:58 GMT+0800 (China Standard Time)

The offered types above seem like good fits for what we would have implemented anyway, and it doesn't seem like we really need sugar for them.

Remi Rousselet · Answer 28 · Thu Jan 10 2019 21:39:33 GMT+0800 (China Standard Time)

it doesn't seem like we really need sugar for them.

I'm not sure about that. This is a very common use-case, and we may have a lot more than just 2 elements.
This leads to unreadable syntax:

type Element = XOR<Foo, XOR<Bar, XOR<Baz, Qux>>>

and the IDE integration is outright disgusting:

with an awesome error message:

Type '{ type: "foo"; bar: number; }' is not assignable to type '(Without<Foo, (Without<Bar, (Without<Baz, Qux> & Qux) | (Without<Qux, Baz> & Baz)> & Without<Baz, Qux> & Qux) | (Without<Bar, (Without<Baz, Qux> & Qux) | (Without<...> & Baz)> & Without<...> & Baz) | (Without<...> & Bar)> & Without<...> & Without<...> & Qux) | (Without<...> & ... 2 more ... & Baz) | (Without<...> & ...'.
  Type '{ type: "foo"; bar: number; }' is not assignable to type 'Without<(Without<Bar, (Without<Baz, Qux> & Qux) | (Without<Qux, Baz> & Baz)> & Without<Baz, Qux> & Qux) | (Without<Bar, (Without<Baz, Qux> & Qux) | (Without<Qux, Baz> & Baz)> & Without<...> & Baz) | (Without<...> & Bar), Foo> & Foo'.
    Type '{ type: "foo"; bar: number; }' is not assignable to type 'Without<(Without<Bar, (Without<Baz, Qux> & Qux) | (Without<Qux, Baz> & Baz)> & Without<Baz, Qux> & Qux) | (Without<Bar, (Without<Baz, Qux> & Qux) | (Without<Qux, Baz> & Baz)> & Without<...> & Baz) | (Without<...> & Bar), Foo>'.
      Types of property 'bar' are incompatible.
        Type 'number' is not assignable to type 'undefined'. [2322]

Claudia Meadows · Answer 29 · Fri Jan 11 2019 03:06:51 GMT+0800 (China Standard Time)

@rrousselGit

That type is wrong anyways. It should be like this, for what most expect:

// T is the type you're checking, and this evaluates to `T extends A ^ B ? T : never`
type XOR<T, A, B> = T extends A & B ? never : T extends A | B ? T : never;

But for most JSON APIs, you don't want an exclusive or - you just want a discriminated union. For your use cases, this is probably sufficient: type Element = FooElement | BarElement.

Remi Rousselet · Answer 30 · Fri Jan 11 2019 04:13:37 GMT+0800 (China Standard Time)

Indeed you're right, my previous example is covered by simple unions, as they were exclusive by default

But the argument still stands. XOR is common enough to be natively included

When we write:

function fn(Foo|Bar);

The expected behavior here is usually a XOR, nor a OR. As the developper likely want to express:

function fn(Foo);
function fn(Bar);

But this requires a lot of code and duplicates. So XOR operator makes it much easier, but then we have very bad compilations errors and IDE integration.

Claudia Meadows · Answer 31 · Sun Jan 13 2019 12:39:12 GMT+0800 (China Standard Time)

@rrousselGit Not my usual expectation, and discriminated unions are just that, unions. Suppose that Foo is type Foo = {type: "foo", foo: 1} and Bar is type Bar = {type: "bar", bar: 2}.

{type: "foo", foo: 1} | {type: "bar", bar: 2} succeeds if the value matches either variant.
No concrete value can match both variants at the same time, so {type: "foo", foo: 1} & {type: "bar", bar: 2} is equivalent to never.
Thus, values can only match one or the other.

It's a type-level design pattern taking advantage of unions and some simple logic to make the conjunction an impossibility. TS doesn't need anything to encapsulate this.

If they shouldn't overlap, don't include overlap. It's that simple. Most JSON APIs even know not to return discriminated unions (enums in JSON Schema parlance), so that's not an issue. The main issue is some server JSON APIs reject extra parameters rather than ignore them, but this is exceedingly rare in my experience with JS libraries.

Remi Rousselet · Answer 32 · Sun Jan 13 2019 13:39:12 GMT+0800 (China Standard Time)

It's a type-level design pattern taking advantage of unions and some simple logic to make the conjunction an impossibility. TS doesn't need anything to encapsulate this.

The thing is, most languages with union type have their | for discriminated unions, not inclusive ones.
This is very strange for typescript to use inclusive unions instead and ask users to implement their custom exclusive union. Especially considering discriminative unions is the most common usage.

Why would we ever want the following to be valid?

type Foo = { bar: number } | { foo: number };
var x: Foo = { bar: 42, foo: 42 }

This defeats the whole point of type guards:

function isBar(value: any): value is Bar {}
function isFoo(value: any): value is Foo {}

function something(value: Foo | Bar) {
  if (isBar(value)) {  }
  else {}
}
function something2(value: Foo | Bar) {
  if (isFoo(value)) {  }
  else {}
}

something and something2 actually have different behaviors, because it is theoretically possible for value to be both Foo and Bar.

Hence the XOR. But as shown before, it's poorly integrated with typescript.

Claudia Meadows · Answer 33 · Sun Jan 13 2019 16:55:44 GMT+0800 (China Standard Time)

@rrousselGit

The thing is, most languages with union type have their | for discriminated unions, not inclusive ones.

No, most such languages only let you specify multiple variants with tags. For example, Haskell's data Either a b = Left a | Right b is morally equivalent to TS's type Either<A, B> = {type: "Left", value: A} | {type: "Right", value: B}.

In some languages, you can still share a variable name across multiple patterns within a single case if the types match. Here's an example of this in Rust, using the built-in Result<T, E> enum that's basically an Either or Choice. (It's defined as enum Result<T, E> { Ok(T), Err(E) }.) This is morally equivalent to something like this in TS:

type Result<A, B> = {type: "Ok", value: A} | {type: "Err", value: B};

const result: Either<number, number> = {type: "Ok", value: 1};

switch (result.type) {
case "Ok": case "Err": console.log(`Result: ${result.value}`); break
}

The main (and really, only) difference here between TS and these other languages is that it understands the concept of a type union without a tag, based mostly in set theory (disjoint unions - disjoint sets, the sets merged via set union, are a special case where their symmetric difference is equivalent to their union). So if you were to define const result: Either<number, string> = ..., then the type of result.value would be number | string rather than just number. Most languages with strong type systems disallow that, but TS aims to be highly interoperable with JS, which often doesn't care about that. Note that with number | string, you can print it, but you can't just do result.value.replace(/foo/g, "bar") unless you check typeof result.value === "string" first. This is why it's not generally a problem that TS is a bit looser with its restrictions.

It's worth mentioning Go has no concept of a discriminated union and is purely structural (more so than even TS).

Marek Buchar · Answer 34 · Tue Apr 30 2019 06:05:42 GMT+0800 (China Standard Time)

just sumbled uppon this ussue ass well and this is my solution for anybody who will land here after me:

// Omit<{ a: string, b: string }, "a">  ==> { b: string }
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>

// PickOne<{ a: string, b: string }, "a"> ==> { a: string; b?: never };
type PickOne<T, K extends keyof T> = Pick<T, K> & { [P in keyof Omit<T, K>]?: never };

// base type with all properties
type M = { m: number, n: number, o: number };

// type that allows EXACTLY ONE property from M
type N = 
   | PickOne<M, "m">
   | PickOne<M, "n">
   | PickOne<M, "o">;

// OK
const n1:N = { m: 42 };
const n2:N = { n: 42 };
const n3:N = { o: 42 };

// Type '{ o: number; x: number; }' is not assignable to type 'N'.
//  Object literal may only specify known properties, and 'x' does not exist in type 'N'.
const n4:N = { o: 42, x: 42 };

//  Type '{ o: number; m: number; }' is not assignable to type 'N'.
//  Type '{ o: number; m: number; }' is not assignable to type 'PickOne<M, "o">'.
//    Type '{ o: number; m: number; }' is not assignable to type '{ m?: never; n?: never; }'.
//      Types of property 'm' are incompatible.
//        Type 'number' is not assignable to type 'never'.
// (same error goes for other conbinations of m, n and o properties)
const n5:N = { m: 42, n: 42 };

only thing, that i didnt figure out is generic declaration of type N:

type P = "m" | "n" | "o";
// same as M above, but uses unit P
type M = { [key in P]: number }

// this one will work only if typeof T === typeof M
// (second param of PickOne must be keyof T - dont know how to enumerate that into union...)
type PickExaclyOne<T> = 
   | PickOne<T, "m">
   | PickOne<T, "n">
   | PickOne<T, "o">;

// ideall way, how to define type N
type N = PickExaclyOne<M>

awei.yu · Answer 35 · Thu Sep 19 2019 22:04:56 GMT+0800 (China Standard Time)

A little more conditional types magic so it works with primitive types:

type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (T | U) extends object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U;

type NameOnly = { is: "NameOnly", name: string };
type FirstAndLastName = { is: "FirstAndLastName", firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>;
let person: Person;

person = { is: "NameOnly", name: "Foo" };
person = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

let stringOrNumber: XOR<string, number>;
stringOrNumber = 14;
stringOrNumber = "foo";

let primitiveOrObject: XOR<string, Person>;

primitiveOrObject= "foo";
primitiveOrObject= { is: "NameOnly", name: "Foo" };
primitiveOrObject= { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

Is this a bug? Live Demo

Igor «InoY» Zviagintsev · Answer 36 · Fri Dec 13 2019 23:41:05 GMT+0800 (China Standard Time)

I've got an error in this sample of code with @EliSnow XOR type https://gist.github.com/inoyakaigor/a7ddca413753c4a3460544348f13f1e9

If change it to
type XOR<T, U> = (T | U) extends Object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U; (Object instead of object) fix it

Nikita Sobolev · Answer 37 · Sun Nov 08 2020 20:06:45 GMT+0800 (China Standard Time)

What about long chains of XOR types? People might have use-cases (like I do) when you have to XOR more than 40 types.

This is how it looks:

export type Task =
    XOR<{ a: AModule },
      XOR<{b: BModule }, 
        XOR<{ c: CModule }, 
          XOR<{ d: DModule }, 
            XOR<{ e: EModule }, { f: FModule }> // ...
          >
        >,
      >
    >;

I would perfer to have:

XOR<
  { a: AModule },
  { b: BModule },
  { c: CModule },
  { d: DModule },
  { e: EModule },
  { f: FModule },
  ...
>

or


^ { a: AModule },
^ { b: BModule },
^ { c: CModule },
^ { d: DModule },
^ { e: EModule },
^ { f: FModule },
//  ...

Related ts-essentials/ts-essentials#183

Kevin Ryan · Answer 38 · Sun Nov 08 2020 20:36:36 GMT+0800 (China Standard Time)

@sobolevn The former isn’t too hard to write in Typescript 4.1:

type AllXOR<T extends any[]> =
    T extends [infer Only] ? Only :
    T extends [infer A, infer B, ...infer Rest] ? AllXOR<[XOR<A, B>, ...Rest]> :
    never;

AllXOR<[
  { a: AModule },
  { b: BModule },
  { c: CModule },
  { d: DModule },
  { e: EModule },
  { f: FModule },
  ...
]>

Before 4.1, you don’t have conditional recursive types, which makes this a pain. There are often ways to get around that, but I don't know what you would need to do to satisfy the compiler there off the top of my head.

Even in 4.1, you will probably run into the “recursion is too long and possibly infinite” error pretty quickly—probably before you could XOR 40 types.

mishoo78 · Answer 39 · Tue Feb 28 2023 17:38:55 GMT+0800 (China Standard Time)

hello,
so this is a 6 years old topic and nothing was done so far; looking at the roadmap, nothing is going to be done.
my question is at this point in time, what is the reason for NOT even discussing this?
what are the technical challenges that prevents this feature to be implemented?
is there an elegant alternative (i do find this xor proposal an ugly hack)
is there an official position / statement / blog ...anything that would at least close this matter?

Ryan Cavanaugh · Answer 40 · Tue Feb 28 2023 23:48:50 GMT+0800 (China Standard Time)

Every suggestion here is approximately 6 to 8 years old, that's what happens when your programming language is ten+ years old and has been popular for 6 to 8 years. If your bar for "it should be done by now" is "it's six years old", then you think TypeScript should have approximately every feature anyone's ever thought of.

kryshac · Answer 41 · Mon Jul 03 2023 19:00:13 GMT+0800 (China Standard Time)

I rewrote the XOR type a bit, which can accept more parameters. The problem for me was not this, it was the problem with "recursion is too long and possibly infinite" @krryan said that the limit was 40 but for me the error appeared from the 10th type, possibly because my types were more complex, I didn't have tested for my variant which is the limit but with 11 it works ok

export type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };

export type SkipUnknown<T, U> = unknown extends T ? never : U;

export type XOR<
  A,
  B,
  C = unknown,
  D = unknown,
  E = unknown,
  F = unknown,
  G = unknown,
  H = unknown,
  I = unknown,
  J = unknown,
  K = unknown,
> =
  | (Without<B & C & D & E & F & G & H & I & J & K, A> & A)
  | (Without<A & C & D & E & F & G & H & I & J & K, B> & B)
  | SkipUnknown<C, Without<A & B & D & E & F & G & H & I & J & K, C> & C>
  | SkipUnknown<D, Without<A & B & C & E & F & G & H & I & J & K, D> & D>
  | SkipUnknown<E, Without<A & B & C & D & F & G & H & I & J & K, E> & E>
  | SkipUnknown<F, Without<A & B & C & D & E & G & H & I & J & K, F> & F>
  | SkipUnknown<G, Without<A & B & C & D & E & F & H & I & J & K, G> & G>
  | SkipUnknown<H, Without<A & B & C & D & E & F & G & I & J & K, H> & H>
  | SkipUnknown<I, Without<A & B & C & D & E & F & G & H & J & K, I> & I>
  | SkipUnknown<J, Without<A & B & C & D & E & F & G & H & I & K, J> & J>
  | SkipUnknown<K, Without<A & B & C & D & E & F & G & H & I & J, K> & K>;

YangLGggggggggg · Answer 42 · Thu Aug 24 2023 17:36:18 GMT+0800 (China Standard Time)

so Is there a best practice for implementing type now ?

the discussion is too long.

we can use ^ now ？ @RyanCavanaugh or use XOR like @mohsen1 said ？

Kostis Maninakis · Answer 43 · Mon Aug 28 2023 23:19:51 GMT+0800 (China Standard Time)

If you ended up here from Google, I've packaged up a working solution complete with tests and documentation and published it on npm as ts-xor.

(shameless plug blah blah but I've ended up needing this way too often and thought I'd make a neat shareable solution I wouldn't feel bad introducing as a dependency at work)

EDIT: ts-xor now supports XORing together up to 200 types, which will hopefully meet the needs that some community members couldn't satisfy with the solutions shared in this issue until now.