Feature Request: "extends oneof" generic constraint; allows for narrowing type parameters

Search Terms

generic bounds
narrow generics
extends oneof

Suggestion

Add a new kind of generic type bound, similar to T extends C but of the form T extends oneof(A, B, C).

(Please bikeshed the semantics, not the syntax. I know this version is not great to write, but it is backwards compatible.)

Similar to T extends C, when the type parameter is determined (either explicitly or through inference), the compiler would check that the constraint holds. T extends oneof(A, B, C) means that at least one of T extends A, T extends B, T extends C holds. So, for example, in a function

function smallest<T extends oneof(string, number)>(x: T[]): T {
    if (x.length == 0) {
        throw new Error('empty');
    }
    return x.slice(0).sort()[0];
}

Just like today, these would be legal:

smallest<number>([1, 2, 3);        // legal
smallest<string>(["a", "b", "c"]); // legal

smallest([1, 2, 3]);               // legal
smallest(["a", "b", "c"]);         // legal

But (unlike using extends) the following would be illegal:

smallest<string | number>(["a", "b", "c"]); // illegal
// string|number does not extend string
// string|number does not extend number
// Therefore, string|number is not "in" string|number, so the call fails (at compile time).

// Similarly, these are illegal:
smallest<string | number>([1, 2, 3]);       // illegal
smallest([1, "a", 3]);                      // illegal

Use Cases / Examples

What this would open up is the ability to narrow generic parameters by putting type guards on values inside functions:

function smallestString(xs: string[]): string {
    ... // e.g. a natural-sort smallest string function
}
function smallestNumber(x: number[]): number {
    ... // e.g. a sort that compares numbers correctly instead of lexicographically
}

function smallest<T extends oneof(string, number)>(x: T[]): T {
    if (x.length == 0) {
        throw new Error('empty');
    }
    const first = x[0]; // first has type "T"
    if (typeof first == "string") {
        // it is either the case that T extends string or that T extends number.
        // typeof (anything extending number) is not "string", so we know at this point that
        // T extends string only.
        return smallestString(x); // legal
    }
    // at this point, we know that if T extended string, it would have exited the first if.
    // therefore, we can safely call
    return smallestNumber(x);
}

This can't be safely done using extends, since looking at one item (even if there's only one item) can't tell you anything about T; only about that object's dynamic type.

Unresolved: Syntax

The actual syntax isn't really important to me; I just would like to be able to get narrowing of generic types in a principled way.

(EDIT:)
Note: despite the initial appearance, oneof(...) is not a type operator. The abstract syntax parse would be more like T extends_oneof(A, B, C); the oneof and the extends are not separate.

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. new expression-level syntax)

(any solution will reserve new syntax, so it's not a breaking change, and it only affects flow / type narrowing so no runtime component is needed)

The use case sounds like a duplicate of #24085, though it seems you've thought through more of the consequences. Let's close this in favor of #24085.

Sounds like you want an "exclusive-or" type operator - similar to #14094.

It is close to a combination of #24085 and #25879 but in a relatively simple way that ensures soundness is preserved.

It only affects generic instantiation and narrowing inside generic functions. No new types or ways of types are being created; an xor operator doesn't do anything to achieve this.

T extends oneof(A, B, C) means that at least one of T extends A, T extends B, T extends C holds.

~~That is what a union constraint does.~~ Do you not mean exactly one of?

That is what a union constraint does.

No because if T = A | B | C then none of T extends A, T extends B, T extends C holds. (Were you reading extends backwards?)

True! No I wasn't, but I had parsed it in my head like (T extends A) | (T extends B) | (T extends C).

What about a XOR type operator? This would be useful in other scenarios as well. As | is a valid bitwise operator in JS for OR, it would fit using ^ as XOR operator in types.

function smallest<T extends string ^ number>(x: T[]): T {
    if (x.length == 0) {
        throw new Error('empty');
    }
    return x.slice(0).sort()[0];
}

Michael De Abreu (@michaeljota)

Michael De Abreu (@michaeljota) See previous comments for why that doesn't work. There is no type today that could be put inside the extends to get the desired behavior. Therefore, new type operations cannot solve this problem, since they just allow you (potentially conveniently) write new types. The type number ^ string is exactly the same as string | number, since there is no overlap between string and number. It does nothing to solve this problem.

This has to be solved by a different kind of constraint rather than a different type in the extends clause.

You want one of a giving list of types, right? I really don't know much about types, sorry. Still, OR operator can be satisfied with n types of the interception, and a XOR operator should only allow one of the types in the interception.

I understand that if you create a interception, string | number, you can use only the functions of both types, and you should narrow down to one of those to use those functions. Also, if you declare a generic type as T extends string | number, then T would accept string, number or string | number. Then a XOR operator used in a generic type as T extends string ^ number should only accept strictly one of string or number, excluding the interception itself string | number.

That's not what you would like this to do?

The problem with that approach is that the ^ is incoherent anywhere outside of an "extends" clause, so it becomes (pointless) syntactic sugar.

For example, what should

var x: string ^ number = 4;

do? Are you allowed to reassign it to "hello"? Or, in more-complicated examples, like:

var x: Array<string ^ number> = [2, 5, "hello"];

why should/shouldn't this be allowed?

There's no coherent way that this can be done. The only way to give it meaning is to only allow it in extends clauses, where it has the meaning of

type Foo<T extends A ^ B> = {}
// means the same thing as
type Foo<T extends_oneof(A, B)> = {}

It still represents a new type of constraint, not a type operator (because it doesn't produce coherent types).

For example, what should
var x: string ^ number = 4;
do? Are you allowed to reassign it to "hello"?

I think it should. In this case, I guess this would behave the same as string | number.

Or, in more-complicated examples, like:
var x: Array<string ^ number> = [2, 5, "hello"];
why should/shouldn't this be allowed?

Here it would be useful, as you either want an array of strings, or an array of numbers, but not both. I think, this would be something like:

var x: Array<string ^ number> = [2, 5, 'hello']
                                ~~~~~~~~~~~~~~~ // Error: Argument of type '(string | number)[]' is not assignable to parameter of type 'string[] | number[]'.

// So (string ^ number)[], would be string[] | number[]

Playground link

This would make #30769 less of a bitter pill to swallow...

Ruben Tytgat (@angryzor)

Ruben Tytgat (@angryzor)

This port concern TypeScript behavior and are not at all a criticism of you or your ideas.

1

As you said, the typescript compiler will infer string | number for this type declaration case:

type A = string[] | number[] extends (infer T)[] ? T[] : never;
//  ?^  (string | number)[]

But if we write it as a type function,

type Id<In> =In extends (infer Out)[] ? Out[] : never;
type X1 = Id<string[]|number[]>;
//  ?^ string[] | number[]

it does not lose precision. For the distribution over the union functionality to work, the function form is required.

2

Another issue: there is some strange TypeScript behavior with the & calculations:

type SN1 = string[] & number[];
//     ^?  string[] & number[]
type T1 = SN1[0];
//   ?^ never

type A = string[] & number[] extends (string & number)[] ? true : false
//   ^? false
type A1 = never[] extends (string & number)[] ? true : false
//   ^? true

type B = (string & number)[] extends string[] & number[] ? true : false
//   ^? true
type B1 = (string & number)[] extends never[] ? true : false
//   ^? true

TypeScript seems to delay the calculation of & at times - as it does here.
Personally I think it would be better to immediately see

type SN1 = string[] & number[];
//     ^?  never[]

A and A1 should be the same, right?
B and B1 should be the same, right?
Also A1 and B1 together imply that never[] and (string & number)[] both extend each other, which I believe should mean they are equal. However they are not equal.
never[] extends (string & number)[] should be true (A1), according to set theory.
(string & number)[] extends never[] should be false (B1), according to set theory.

Conclusion

TypeScript handling of types at sets is not really mathematically precise.
At least, there are a few corner cases that I think TypeScript does not properly handle (as of V5.3.3).

Han Seoul-Oh (@laughinghan)

I think that this cannot be closed yet. It is unsolved.

Han Seoul-Oh (@laughinghan), your given example fixes the problem of using a function that allows T1 or T2 but not T1|T2 union.

In my opinion that is not the problem (because it has a solution). The problem is implementing that function. Inside that function you cannot have a generic type T that can be T1 or T2 but not T1|T2. That is specialy bad for numeric types.

See my example in my previous comment: #27808 (comment)

Emilio (@emilioplatzer)

Emilio (@emilioplatzer) Thank you, that's a much better example. Can we update the main issue description then? Both to mention the better example, and to mention that function overloads are an (incomplete) workaround. The fact that the best workaround requires annoying casts is a pretty good argument for this feature:

function add(a: number, b: number): number
function add(a: bigint, b: bigint): bigint
function add<Num extends bigint | number>(a: Num, b: Num): bigint | number {
    return (a as number) + (b as number);
}

More generally TypeScript doesn't really track correlations between types much at all (with distributive conditional types being a very limited exception); this does seem like potentially a small, practical way to specify type correlations in some useful cases.

Han Seoul-Oh (@laughinghan)

Han Seoul-Oh (@laughinghan) Emilio (@emilioplatzer) Nathan Fenner (@Nathan-Fenner)

There are really 3 separate items that are related:

Specifying the call parameter and return type correlations.
Using those correlations for flow analysis inside the function implementation and to validate the return statements therein.
Using those correlations to validate calls to the function.

Item 3 is already working, item 2 is not.

Notice that Emilio (@emilioplatzer) post says

Inside that function you cannot have a generic type T that can be T1 or T2 but not T1|T2.

That is talking about item 3.

The OP #27808 title implies that a new form for specifying correlations (extends oneof) is the main feature - that feature belongs to item 1. However, the OP long content also talks about item 3.

It is possible to fix item 3 without adding a new feature for item 1.
It is possible to add a new oneof feature for item 1 without fixing item 3.

Joe Calzaretta (@jcalz)

ts playground

Isn't it just a syntax sugar for writing more function overloads? You can achieve the same functionality with a few type helpers:

(Thanks to Joe Calzaretta (@jcalz) for UnionToIntersection magic on stackoverflow)

Helpers

Definition

type UnionToIntersection<U> =
  (U extends any ? (_: U) => void : never) extends ((_: infer I) => void) ? I : never

// Here you define how your function overload will look
type Render<OneOfPossibleOptions> = <const T extends OneOfPossibleOptions>(x: T[]) => T

type ConvertTupleOfPossibleOptionsToOverloadsUnion<
  TupleOfPossibleOptions
> = TupleOfPossibleOptions extends [infer OneOfPossibleOptions, ...infer RestOfPossibleOptions]
    ?
      | Render<OneOfPossibleOptions>
      | ConvertTupleOfPossibleOptionsToOverloadsUnion<RestOfPossibleOptions>
    : never;

type ConvertTupleOfPossibleOptionsToOverloadsIntersection<
  TupleOfPossibleOptions
> = UnionToIntersection<
  ConvertTupleOfPossibleOptionsToOverloadsUnion<
    TupleOfPossibleOptions
  >
>;

Tests and usage

import { Equals, assert } from 'tsafe';

// since ts doesn't have a way to reliably compare equality of types
// (including comparing overloads like `{
//   (_: ('A' | 'B')[]):  ('A' | 'B');
//   (_: ('C' | 'D')[]):  ('C' | 'D');
// }` to function intersections which I'm trying to do here), I wrote the
// expected test value in `((...) => ...) & ((...) => ...)` form instead of
// overload type form like `{(...) => ...; (...) => ...}`
// https://github.com/microsoft/TypeScript/issues/48100
// https://github.com/microsoft/TypeScript/issues/27024

assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<['A' | 'B', 'C' | 'D']>,
  & (<const T extends ('A' | 'B')>(_: T[]) => T)
  & (<const T extends ('C' | 'D')>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<['A'      , 'C' | 'D']>,
  & (<const T extends ('A'      )>(_: T[]) => T)
  & (<const T extends ('C' | 'D')>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<[      'B', 'C' | 'D']>,
  & (<const T extends (      'B')>(_: T[]) => T)
  & (<const T extends ('C' | 'D')>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<['A' | 'B', 'C'      ]>,
  & (<const T extends ('A' | 'B')>(_: T[]) => T)
  & (<const T extends ('C'      )>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<['A'      , 'C'      ]>,
  & (<const T extends ('A'      )>(_: T[]) => T)
  & (<const T extends ('C'      )>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<[      'B', 'C'      ]>,
  & (<const T extends (      'B')>(_: T[]) => T)
  & (<const T extends ('C'      )>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<['A' | 'B',       'D']>,
  & (<const T extends ('A' | 'B')>(_: T[]) => T)
  & (<const T extends (      'D')>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<['A'      ,       'D']>,
  & (<const T extends ('A'      )>(_: T[]) => T)
  & (<const T extends (      'D')>(_: T[]) => T)
>>
assert<Equals<ConvertTupleOfPossibleOptionsToOverloadsIntersection<[      'B',       'D']>,
  & (<const T extends (      'B')>(_: T[]) => T)
  & (<const T extends (      'D')>(_: T[]) => T)
>>

Example 1

Definition

const fruits = ['apple', 'orange', 'banana'] as const satisfies unknown[]; // to remove readonliness
const colors = ['red',   'green',  'blue'  ] as const satisfies unknown[]; // to remove readonliness

type FruitsUnion = typeof fruits[number];
type ColorsUnion = typeof colors[number];

const getRandomElementFromEitherArrayOfFruitsOrColors:
  ConvertTupleOfPossibleOptionsToOverloadsIntersection<[FruitsUnion, ColorsUnion]>
= <const T extends FruitsUnion[] | ColorsUnion[]>(arr: T) => {
  const doesArrHave = <T extends unknown[]>(valuesToLookFor: T) => arr.some((x) => valuesToLookFor.includes(x) )
  const doesArrHaveOnly = <T extends unknown[]>(valuesToLookFor: T) => arr.every((x) => valuesToLookFor.includes(x) )

  if (doesArrHave(fruits) && doesArrHave(colors))
    throw new Error('Mixing fruits with Colors is not allowed')

  if (!doesArrHave(fruits) && !doesArrHave(colors))
    throw new Error('getRandomElementFromEitherArrayOfFruitsOrColors has nothing to choose from.')

  if (
    (doesArrHave(fruits) && !doesArrHaveOnly(fruits))
    ||
    (doesArrHave(colors) && !doesArrHaveOnly(colors))
  )
    throw new Error("getRandomElementFromEitherArrayOfFruitsOrColors takes either only fruits or only colors")


  const randomElement = arr[Math.floor(Math.random() * arr.length)];
  return randomElement as T[number];
}

Tests and usage

// Maria likes apples more, so we increase it's probability, and she also
// hates oranges, so we remove them
const getRandomFruitForMaria =
  () => getRandomElementFromEitherArrayOfFruitsOrColors(['apple', 'apple', 'apple', 'banana']);

assert<Equals<typeof getRandomFruitForMaria, () => 'apple' | 'banana'>>;


// John has no preference for colors
const getRandomColorForJohn = () => getRandomElementFromEitherArrayOfFruitsOrColors(colors);

assert<Equals<typeof getRandomColorForJohn, () => 'red' | 'green' | 'blue'>>;


try {
  // @ts-expect-error Expected 1 arguments, but got 0.ts(2554)
  getRandomElementFromEitherArrayOfFruitsOrColors()
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}


try {
  // @ts-expect-error No overload matches this call.
  //   Overload 1 of 2, '(x: ("apple" | "orange" | "banana")[]): "apple" | "orange" | "banana"', gave the following error.
  //   Type '"asd"' is not assignable to type '"apple" | "orange" | "banana"'.
  // Overload 2 of 2, '(x: ("red" | "green" | "blue")[]): "red" | "green" | "blue"', gave the following error.
  //   Type '"asd"' is not assignable to type '"red" | "green" | "blue"'.ts(2769)
  getRandomElementFromEitherArrayOfFruitsOrColors(['asd'])
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}


// should not throw errors
getRandomElementFromEitherArrayOfFruitsOrColors(['apple'])


// should not throw errors
getRandomElementFromEitherArrayOfFruitsOrColors(['red'])


try {
  // @ts-expect-error No overload matches this call.
  //   Overload 1 of 2, '(x: ("apple" | "orange" | "banana")[]): "apple" | "orange" | "banana"', gave the following error.
  //   Type '"red"' is not assignable to type '"apple" | "orange" | "banana"'.
  // Overload 2 of 2, '(x: ("red" | "green" | "blue")[]): "red" | "green" | "blue"', gave the following error.
  //   Type '"apple"' is not assignable to type '"red" | "green" | "blue"'.ts(2769)
  getRandomElementFromEitherArrayOfFruitsOrColors(['apple', 'red'])
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}


try {
  // @ts-expect-error No overload matches this call.
  //   Overload 1 of 2, '(x: ("apple" | "orange" | "banana")[]): "apple" | "orange" | "banana"', gave the following error.
  //   Type '"red"' is not assignable to type '"apple" | "orange" | "banana"'.
  // Overload 2 of 2, '(x: ("red" | "green" | "blue")[]): "red" | "green" | "blue"', gave the following error.
  //   Type '"apple"' is not assignable to type '"red" | "green" | "blue"'.ts(2769)
  getRandomElementFromEitherArrayOfFruitsOrColors(['red', 'apple'])
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}

Example 2 (to show applicability to the OP's example)

Definition

const getSmallestElement: ConvertTupleOfPossibleOptionsToOverloadsIntersection<[string, number]> =
  <T extends string[] | number[]>(arr: T) => {
    const doesArrHaveValuesConforming = <T extends unknown[]>(rule: (t: unknown) => t is T[number]) => arr.some((x) => rule(x) )
    const doesArrHaveOnlyValuesConforming = <T extends unknown[]>(rule: (t: unknown) => t is T[number]) => arr.every((x) => rule(x) )
    const doesArrayHasStrings = doesArrHaveValuesConforming(t => typeof t === 'string');
    const doesArrayHasNumbers = doesArrHaveValuesConforming(t => typeof t === 'number');
    const doesArrayHasOnlyStrings = doesArrHaveOnlyValuesConforming(t => typeof t === 'string');
    const doesArrayHasOnlyNumbers = doesArrHaveOnlyValuesConforming(t => typeof t === 'number');

    if (doesArrayHasStrings && doesArrayHasNumbers)
      throw new Error('Mixing strings with numbers is not allowed')

    if (!doesArrayHasStrings && !doesArrayHasNumbers)
      throw new Error('getSmallestElement has nothing to choose from.')

    if (
      (doesArrayHasStrings && !doesArrayHasOnlyStrings)
      ||
      (doesArrayHasNumbers && !doesArrayHasOnlyNumbers)
    )
      throw new Error("getSmallestElement takes either only strings or only numbers")

    return arr.toSorted()[0] as T[number];
  }

Tests and usage

const smallestOf6Numbers =
  getSmallestElement([4, 0, 1, 2, 3, 4])

assert<Equals<typeof smallestOf6Numbers, 0 | 2 | 1 | 3 | 4>>(smallestOf6Numbers === 0);


const smallestOf6Strings =
  getSmallestElement(['4', '0', '1', '2', '3', '4'])

assert<Equals<typeof smallestOf6Strings, '0' | '1' | '2' | '3' | '4'>>(smallestOf6Strings === '0');


const smallestOf6Strings2 =
  getSmallestElement(['a', 'b', 'c', 'd', 'e', 'f'])

assert<Equals<typeof smallestOf6Strings2, 'a' | 'b' | 'c' | 'd' | 'e' | 'f'>>(smallestOf6Strings2 === 'a');


try {
  // @ts-expect-error Expected 1 arguments, but got 0.ts(2554)
  getSmallestElement()
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}


try {
  // @ts-expect-error No overload matches this call.
  // Overload 1 of 2, '(x: string[]): string', gave the following error.
  //   Type 'boolean' is not assignable to type 'string'.
  // Overload 2 of 2, '(x: number[]): number', gave the following error.
  //   Type 'boolean' is not assignable to type 'number'.ts(2769)
  getSmallestElement([false])
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}


// should not throw errors
getSmallestElement(['000'])


// should not throw errors
getSmallestElement([0])


try {
  // @ts-expect-error No overload matches this call.
  // Overload 1 of 2, '(x: string[]): string', gave the following error.
  //   Type 'number' is not assignable to type 'string'.
  // Overload 2 of 2, '(x: number[]): number', gave the following error.
  //   Type 'string' is not assignable to type 'number'.ts(2769)
  getSmallestElement(['000', 0])
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}


try {
  // @ts-expect-error No overload matches this call.
  // Overload 1 of 2, '(x: string[]): string', gave the following error.
  //   Type 'number' is not assignable to type 'string'.
  // Overload 2 of 2, '(x: number[]): number', gave the following error.
  //   Type 'string' is not assignable to type 'number'.ts(2769)
  getSmallestElement([0, '000'])
  console.error("Failed to fail :(")
} catch (error) {
  console.info('Successfully failed :)',error)
}

EVA (Entity Value Attribute) (@nikelborm)

EVA (Entity Value Attribute) (@nikelborm) excellent answer.

here's a slightly more flexible version that would accept the render method as parameter:


export type TupleToUnion<T extends readonly unknown[]> = T[number];

export type UnionToIntersection<U> =
    (U extends any ? (_: U) => void : never) extends ((_: infer I) => void) ? I : never;

export type GenericFunction<
    Generics extends any[] = [],
    Args extends any[] = [],
    Return = any
> = <G extends Generics, A extends Args>(...args: A) => Return;

export type ConvertTupleOfPossibleOptionsToOverloadsUnion<
    TupleOfPossibleOptions extends readonly any[],
    Render extends GenericFunction<any, any, any>
> = TupleOfPossibleOptions extends [infer OneOfPossibleOptions, ...infer RestOfPossibleOptions]
    ? | Render
    | ConvertTupleOfPossibleOptionsToOverloadsUnion<RestOfPossibleOptions, Render>
    : never;

export type $overload<
    TFunc extends GenericFunction<any, any, any>,
    TAgainst extends readonly any[]
> = UnionToIntersection<
    ConvertTupleOfPossibleOptionsToOverloadsUnion<
        TAgainst,
        TFunc
    >
>

// Example usage:
declare type PossibleOptions = ['a', 'b', 'c'];
type RenderFindAll<OneOfPossibleOptions> = <const T extends OneOfPossibleOptions>(x: T) => T;
declare const method: $overload<RenderFindAll<TupleToUnion<PossibleOptions>>, PossibleOptions>;

const r = method('a'); // r is 'a'

EVA (Entity Value Attribute) (@nikelborm)

EVA (Entity Value Attribute) (@nikelborm) and Wahib Mkadmi (@TheRealMkadmi): I don't have time to test out your implemenations, but it's cool to hear that this is already possible to some extent. Could I interest you in contributing to https://github.com/sindresorhus/type-fest/ so that it's easy for others to use your implementations? 😄

this would be a great addition for when one wants to constrain a type with keyof but also ensure it is always a single key, and not something like "key1" | "key2"

I’m sure a similar solution already exists, but something close to this is already possible:

type As<T, _Infer extends T> = unknown
type OneOf<T extends unknown[]> = unknown extends As<keyof T & `${number}`, infer I>
    ? I extends unknown
        ? T[I][]
        : never
    : never
;

const lol = <T extends OneOf<[string, number]>>(args: T) => args;

lol([1, 2, 3]);                                 // legal
lol(['a', 'b', 'c']);                           // legal

lol<OneOf<[string | number]>>(["a", "b", "c"]); // illegal
lol([1, "a", 3]);                               // illegal

Edit: to provide a bit more context, this is equivalent to the following:

const lol = <T extends string[] | number[]>(args: T) => args;

While presumably much more niche, it's worth noting that nof also seems to work reasonably well:

NOf Implementation

type As<T, _Infer extends T> = unknown;
type RangeInternal<T extends number, TArr extends number[]> = TArr['length'] extends T
    ? TArr
    : RangeInternal<T, [...TArr, TArr['length']]>
;
type Range_<T extends number> = RangeInternal<T, []>;
type Decrement<T extends number> = Range_<T> extends [unknown, ...infer Rest]
    ? Rest['length']
    : never
;

type ValueOf<T> = T[keyof T];
type NOfInternal<T extends Record<number, unknown>, TCount extends number> = TCount extends 0
    ? []
    : ValueOf<{
        [I in keyof T & `${number}`]: [
            T[I],
            ...NOfInternal<Omit<T, I>, Decrement<TCount>>
        ]
    }>
;
type NOf<
    T extends unknown[],
    TCount extends number
> = unknown extends As<NOfInternal<T, TCount>, infer V>
    ? V extends unknown
        ? V[number][]
        : never
    : never
;

// Usage

type Allowed = ['a', 'b', 'c'];

const oneOf = <T extends NOf<Allowed, 1>>(args: T) => args;
const twoOf = <T extends NOf<Allowed, 2>>(args: T) => args;

oneOf(['a', 'a']); // legal
oneOf(['a', 'b']); // illegal
twoOf(['a', 'b']); // legal

Please don't post enormous AI summaries. Leave that to me 🙂

Please don't post enormous AI summaries. Leave that to me 🙂

😢

Maybe used Ai to articulate but it was very well thought out. Went over what's written many many times to make sure it's accurate... Understandable though why it might be disruptive...

Can I repost my version of implementation without the gibergaber though? Might be helpful for others

Really worked hard on this post 😭
Would love if at least you could go over it and see if there's at least a bit if merit to it and if it has possibly new approaches or value

I'm not really sure what you're trying to accomplish with it, so I can't speak to how to better achieve that goal

a possible solution is to make (the simple identifer) oneof a special marker type with said one-of semantics:

function smallest<T extends oneof<[C1, C2, C3, ...]> /* T must therefore subclass either */>(x: T[]): T

interface Smallest<T extends oneof<[C1, C2, C3, ...] /* T must therefore subclass either */, T2>

function processStat<const T>(r: oneof<[Failure, Success<T> ]> /* 'r' must therefore conform to either */): StatResp

usage other than as said will simply result in plain C1 | C2 | C3 | ...s (since extends oneof<[C1, C2, C3, ...]> mathematically implies extends C1 | C2 | C3 - as others pointed out)
and may additionally be flagged (illegal 'oneof' application)

other examples of 'special marker types' include NoInfer and ThisType.
- possible future work: interface C extends Opaque<CBase> (Support some non-structural (nominal) type matching #202)

Navigation Menu

Repository navigation

Feature Request: "extends oneof" generic constraint; allows for narrowing type parameters #27808

Search Terms

Suggestion

Use Cases / Examples

Unresolved: Syntax

Checklist

67 remaining items

1

2

Conclusion

Helpers

Definition

Tests and usage

Example 1

Definition

Tests and usage

Example 2 (to show applicability to the OP's example)

Definition

Tests and usage

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature Request: "extends oneof" generic constraint; allows for narrowing type parameters #27808

Description

Search Terms

Suggestion

Use Cases / Examples

Unresolved: Syntax

Checklist

Activity

mattmccutchen commented on Oct 11, 2018

DanielRosenwasser commented on Oct 11, 2018

Nathan-Fenner commented on Oct 12, 2018

jack-williams commented on Oct 12, 2018

mattmccutchen commented on Oct 12, 2018

jack-williams commented on Oct 12, 2018

michaeljota commented on Apr 29, 2019

Nathan-Fenner commented on Apr 29, 2019

michaeljota commented on Apr 29, 2019

Nathan-Fenner commented on Apr 29, 2019

michaeljota commented on Apr 29, 2019

jcalz commented on Jun 6, 2019

67 remaining items

craigphicks commented on Dec 8, 2023

1

2

Conclusion

emilioplatzer commented on Dec 9, 2023

laughinghan commented on Dec 11, 2023

craigphicks commented on Dec 11, 2023

nikelborm commented on Oct 25, 2024

Helpers

Definition

Tests and usage

Example 1

Definition

Tests and usage

Example 2 (to show applicability to the OP's example)

Definition

Tests and usage

TheRealMkadmi commented on Oct 27, 2024

lgarron commented on Oct 28, 2024

marcospgp commented on Jun 27, 2025

codpro2005 commented on Oct 13, 2025

codpro2005 commented on Oct 14, 2025

lyle45 commented on Oct 20, 2025

RyanCavanaugh commented on Oct 20, 2025

lyle45 commented on Oct 21, 2025

RyanCavanaugh commented on Oct 21, 2025

irfanstract commented on Aug 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions