Type manipulations: union to tuple

[krryan]

A suggestion to create a runtime array of union members was deemed out of scope because it would not leave the type system fully erasable (and because it wouldn't be runtime complete, though that wasn't desired). This suggestion is basically a variant of that one that stays entirely within the type domain, and thus stays erasable.

The suggestion is for a keyword similar to keyof that, when given a union type, would result in a tuple type that includes each possibility in the union.

Combined with the suggestion in this comment to instead implement a codefix to create the array literal, this could be used to ensure that 1. the array was created correctly to begin with, and 2. that any changes to the union cause an error requiring the literal array to be updated. This allows creating test cases that cover every possibility for a union.

Syntax might be like this:

type SomeUnion = Foo | Bar;

type TupleOfSomeUnion = tupleof SomeUnion; // has type [Foo, Bar]

type NestedUnion = SomeUnion | string;

type TupleOfNestedUnion = tupleof NestedUnion; // has type [Foo, Bar, string]

Some issues I foresee:

1. I don't know what ordering is best (or even feasible), but it would have to be nailed down in some predictable form.

2. Nesting is complicated.

3. I expect generics would be difficult to support?

4. Inner unions would have to be left alone, which is somewhat awkward. That is, it would not be reasonable to turn Wrapper<Foo|Bar> into [Wrapper<Foo>, Wrapper<Bar>] even though that might (sometimes?) be desirable. In some cases, it’s possible to use conditional types to produce that distribution, though it has to be tailored to the particular Wrapper. Some way of converting back and forth between Wrapper<Foo|Bar> and Wrapper<Foo>|Wrapper<Bar> would be nice but beyond the scope of this suggestion (and would probably require higher-order types to be a thing).

5. My naming suggestions are weak, particularly tupleof.

NOTE: This suggestion originally also included having a way of converting a tuple to a union. That suggestion has been removed since there are now ample ways to accomplish that. My preference is with conditional types and infer, e.g. ElementOf<A extends unknown[]> = A extends (infer T)[] ? T : never;.

[zpdDG4gta8XKpMCd]

functionof would not hurt either: #12265

[aleclarson]

You can already do tuple -> union conversion:

[3, 1, 2][number] // => 1 | 2 | 3

type U<T extends any[], U = never> = T[number] | U
U<[3, 1, 2]> // => 1 | 2 | 3
U<[1], 2 | 3> // => 1 | 2 | 3

How about a concat operator for union -> tuple conversion?

type U = 1 | 2 | 3
type T = [0] + U        // => [0, 1, 2, 3]
type S = U + [0]        // => [1, 2, 3, 0]
type R = [1] + [2]      // => [1, 2]
type Q = R + R          // => [1, 2, 1, 2]
type P = U + U          // Error: cannot use concat operator without >=1 tuple
type O = [] + U + U     // => [1, 2, 3, 1, 2, 3]
type N = [0] + any[]    // => any[]
type M = [0] + string[] // Error: type '0' is not compatible with 'string'
type L = 'a' + 16 + 'z' // => 'a16z'

Are there good use cases for preserving union order? (while still treating unions as sets for comparison purposes)

[krryan]

I had used a conditional type for tuple to union:

type ElementOf<T> = T extends (infer E)[] ? E : T;

Works for both arrays and tuples.

[ShanonJackson]

or just [1,2,3][number] will give you 1 | 2 | 3

[ShanonJackson]

Decided to stop being a lurker and start joining in the Typescript community alittle more hopefully this contribution helps put this Union -> Tuple problem to rest untill Typescript hopefully gives us some syntax sugar.

This is my "N" depth Union -> Tuple Converter that maintains the order of the Union

// add an element to the end of a tuple
type Push<L extends any[], T> =
  ((r: any, ...x: L) => void) extends ((...x: infer L2) => void) ?
    { [K in keyof L2]-?: K extends keyof L ? L[K] : T } : never

export type Prepend<Tuple extends any[], Addend> = ((_: Addend, ..._1: Tuple) => any) extends ((
    ..._: infer Result
) => any)
    ? Result
    : never;
//
export type Reverse<Tuple extends any[], Prefix extends any[] = []> = {
    0: Prefix;
    1: ((..._: Tuple) => any) extends ((_: infer First, ..._1: infer Next) => any)
        ? Reverse<Next, Prepend<Prefix, First>>
        : never;
}[Tuple extends [any, ...any[]] ? 1 : 0];

// convert a union to an intersection: X | Y | Z ==> X & Y & Z
type UnionToIntersection<U> =
  (U extends any ? (k: U) => void : never) extends ((k: infer I) => void) ? I : never

// convert a union to an overloaded function X | Y ==> ((x: X)=>void) & ((y:Y)=>void)     
type UnionToOvlds<U> = UnionToIntersection<U extends any ? (f: U) => void : never>;

// returns true if the type is a union otherwise false
type IsUnion<T> = [T] extends [UnionToIntersection<T>] ? false : true;

// takes last from union
type PopUnion<U> = UnionToOvlds<U> extends ((a: infer A) => void) ? A : never;

// takes random key from object
type PluckFirst<T extends object> = PopUnion<keyof T> extends infer SELF ? SELF extends keyof T ? T[SELF] : never;
type ObjectTuple<T, RES extends any[]> = IsUnion<keyof T> extends true ? {
    [K in keyof T]: ObjectTuple<Record<Exclude<keyof T, K>, never>, Push<RES, K>> extends any[]
        ? ObjectTuple<Record<Exclude<keyof T, K>, never>, Push<RES, K>>
        : PluckFirst<ObjectTuple<Record<Exclude<keyof T, K>, never>, Push<RES, K>>>
} : Push<RES, keyof T>;

/** END IMPLEMENTATION  */

type TupleOf<T extends string> = Reverse<PluckFirst<ObjectTuple<Record<T, never>, []>>>

interface Person {
    firstName: string;
    lastName: string;
    dob: Date;
    hasCats: false;
}
type Test = TupleOf<keyof Person> // ["firstName", "lastName", "dob", "hasCats"]

[krryan]

Finally removed the bit about union to tuple, since there are plenty of ways to do that now (there weren’t when this suggestion was first made). Also, much thanks to @ShanonJackson, that looks awesome and I will have to try that. Still, that’s a lot of code for this; sugar would be rather appreciated here. Or at least a built-in type that comes with Typescript, so that doesn’t have to be re-implemented in every project.

[aleclarson]

@krryan A solution of that size should be published as an NPM package, IMO.

Worth noting: The TupleOf type provided by @ShanonJackson only supports string unions, so it's not a universal solution by any means.

[krryan]

@aleclarson Yes, but installing a dependency is, to my mind, still “reimplementing” it, at least in the context here. Sure, an NPM package is superior to copying and pasting that code around. But I don’t think either should be necessary for this. It’s a language construct that is broadly useful to all Typescript developers, in my opinion, so it should just be available (and quite possibly be implemented more easily within tsc than as a type in a library).

Anyway, good point about the string limitation; that’s quite severe (I might still be able to use that but it’s going to take some work since I’ll have to get a tuple of my discriminants and then distribute those appropriately, but I think it will work for my purposes).

[dragomirtitian]

@ShanonJackson

I fear that while this solution works, it is very compiler unfriendly .. I added just a couple more keys to the object and when I hovered over it the language server got up to 100% CPU usage, ate up 3GB of RAM and no tooltips ever show up.

interface Person {
    firstName: string;
    lastName: string;
    dob: Date;
    hasCats: false;
    hasCats1: false;
    hasCats2: false;
    hasCats3: false;
    hasCats4: false;
}
type Test = TupleOf<keyof Person> //  tool tip never shows up HUGE amount of RAM and CPU Used,

[RyanCavanaugh]

Sorry this has been stuck in Need Investigation so long!

My primary question is: What would this be useful for? Hearing about use cases is really important; the suggestion as it stands seems like an XY problem situation.

Secondary comments: This suggestion could almost certainly never happen; problems with it are many.

First, union order is not something we can ever allow to be observable. Internally, unions are stored as a sorted list of types (this is the only efficient way to quickly determine relationships between them), and the sort key is an internal ID that's generated incrementally. The practical upshot of this is that two extremely similar programs can generate vastly different union orderings, and the same union observed in a language service context might have a different ordering than when observed in a commandline context, because the order in which types are created is simply the order in which they are checked.

Second, there are basic identities which are very confusing to reason about. Is tupleof T | ( U | V ) [T, U | V] or [T, U, V] ? What about this?

// K always has arity 2?
type K<T, U> = tupleof (T | U);
// Or Q has arity 3? Eh?
type Q = K<string, number | boolean>;

There are more problems but the first is immediately fatal IMO.

[krryan]

@RyanCavanaugh The primary use-case for me is to ensure complete coverage of all the types that a function claims to be able to handle in testing scenarios. There is no way to generate an array you can be sure (tsc will check) has every option.

Order doesn’t matter to me at all, which makes it frustrating to have that as a fatal flaw. I think Typescript programmers are already familiar with union ordering being non-deterministic, and that’s never really been a problem. I wonder if creating something typed as Set<MyUnion> but with a fixed size (i.e. equal to the number of members of MyUnion) would be more valid? Sets are ordered, but that would be at runtime, rather than exposed as part of its type, which maybe makes it acceptable (since it’s not part of the type, looking at the code you have no reason to expect any particular order).

As for T | ( U | V ) I would definitely want that to be [T, U, V]. On K and Q, those results (arity 2, arity 3) don’t seem surprising to me and seem quite acceptable. I’m maybe not seeing the issue you’re getting at?

[dragomirtitian]

@krryan Yes but the problem is that if 'A' | 'B' gets transformed to ['A', 'B'] it should always be transformed to ['A', 'B']. Otherwise you will get random errors at invocation site. I think the point @RyanCavanaugh is making is that this order cannot be guaranteed 100% of the time and may depend on the order and the sort key which is "... an internal ID that generated incrementally"

type  A = "A"
type  B = "B"

type AB = A | B
function tuple(t: tupleof AB) {}

tuple(['A', 'B'])// Change the order in which A and B are declared and this becomes invalid .. very brittle ...

[ShanonJackson]

Yes tuples have a strict order unless you write a implementation that can turn [A, B] into [A, B] | [B, A] (permutations). However such a type-level implementation would also be very heavy on the compiler without syntax sugar as when you get up to 9! you get into some ridiculous amount of computation that a recursive strategy will struggle.

If people do care about the order (i don't) then i think just write a implementation that turns [A, B] into... [A | B, A | B] intersected with a type that makes sure both A & B are present? therefore you can't go [A, A] and also can't go [A, A, B] but can go[A, B] or [B, A]

[krryan]

@dragomirtitian I fully understand that, which is why I suggested some alternative type that isn’t a tuple type to indicate that we are talking about an unordered set of exactly one each of every member of a union.

Which it now dawns on me can be accomplished for strings by creating a type that uses every string in a union of strings as the properties of a type. For example:

const tuple = <T extends unknown[]>(...a: T): T => a;

type ElementOf<T> = T extends Array<infer E> ? E : T extends ReadonlyArray<infer E> ? E : never;
type AreIdentical<A, B> = [A, B] extends [B, A] ? true : false;

type ObjectWithEveryMemberAsKeys<U extends string> = {
    [K in U]: true;
};

const assertTupleContainsEvery = <Union extends string>() =>
    <Tuple extends string[]>(
        tuple: Tuple,
    ) =>
        tuple as AreIdentical<
            ObjectWithEveryMemberAsKeys<Union>,
            ObjectWithEveryMemberAsKeys<ElementOf<Tuple>>
        > extends true ? Tuple : never;

const foo = 'foo' as const;
const bar = 'bar' as const;
const baz = 'baz' as const;
const assertContainsFooBar = assertTupleContainsEvery<typeof foo | typeof bar>();
const testFooBar = assertContainsFooBar(tuple(foo, bar)); // correctly ['foo', 'bar']
const testBarFoo = assertContainsFooBar(tuple(bar, foo)); // correctly ['bar', 'foo']
const testFoo = assertContainsFooBar(tuple(foo)); // correctly never
const testFooBarBaz = assertContainsFooBar(tuple(foo, bar, baz)); // correctly never
const testFooBarBar = assertContainsFooBar(tuple(foo, bar, bar)); // incorrectly ['foo', 'bar', 'bar']; should be never

There’s probably a way to fix the foo, bar, bar case, and in any event that’s the most minor failure mode. Another obvious improvement is to change never to something that would hint at what’s missing/extra, for example

        > extends true ? Tuple : {
            missing: Exclude<Union, ElementOf<Tuple>>;
            extra: Exclude<ElementOf<Tuple>, Union>;
        };

though that potentially has the problem of a user thinking it’s not an error report but actually what the function returns, and trying to use .missing or .extra (consider this another plug for #23689).

This works for strings (and does not have the compiler problems that the suggestion by @ShanonJackson has), but doesn’t help non-string unions. Also, for that matter, my real-life use-case rather than Foo, Bar, Baz is getting string for ElementOf<Tuple> even though on hover the generic inferred for Tuple is in fact the tuple and not string[], which makes me wonder if TS is shorting out after some number of strings and just calling it a day with string.

[RyanCavanaugh]

The primary use-case for me is to ensure complete coverage of all the types that a function claims to be able to handle in testing scenarios

How do tuples, as opposed to unions, help with this? I'm begging y'all, someone please provide a hypothetical code sample here for what you'd do with this feature so I can understand why 36 people upvoted it 😅

Order doesn’t matter to me

I can accept this at face value, but you have to recognize that it'd be a never-ending source of "bug" reports like this. The feature just looks broken out of the gate:

type NS = tupleof number | string;
// Bug: This is *randomly* accepted or an error, depending on factors which
// can't even be explained without attaching a debugger to tsc
const n: NS = [10, ""];

I question whether it's even a tuple per se if you're not intending to test assignability to/from some array literal.

[KiaraGrouwstra]

@RyanCavanaugh:

Is tupleof T | ( U | V ) [T, U | V] or [T, U, V] ?

I'm with @krryan -- only the latter makes sense here. The former would seem quite arbitrary.

union order is not something we can ever allow to be observable.

This is perfectly, as this is not a blocker to its use-cases.

My primary question is: What would this be useful for? Hearing about use cases is really important; the suggestion as it stands seems like an XY problem situation.

One big problem I see this as solving is map functions on objects (Lodash's mapValues, Ramda's map), which this would allow accurately typing even for heterogeneous objects (-> calculating value types for each key), i.e. what's solved by Flow's $ObjMap, though this implies getting object type's keys, converting them to a union, then converting this union to a tuple type, then using type-level iteration through this tuple using recursive types so as to accumulate value types for each key.

TupleOf may let us do this today. I don't expect this to be a supported use-case of TypeScript. Going through this to type one function may sound silly. But I think it's kind of big.

Anyone who has used Angular's state management library ngrx will be aware that getting type-safe state management for their front-end application involves horrific amounts of boilerplate. And in plain JavaScript, it has always been easy to imagine an alternative that is DRY.

Type-safe map over heterogeneous objects addresses this for TypeScript, by allowing granular types to propagate without requiring massive amounts of boilerplate, as it lets you separate logic (functions) from content (well-typed objects).

edit: I think this depends on the boogieman $Call as well. :neutral_face:

[treybrisbane]

I basically just want to be able to do this:

const objFields: [['foo', 3], ['bar', true]] = entries({ foo: 3, bar: true });

I'm not sure whether the ES spec guarantees ordering of object entries or not. Node's implementation seems to, but if the spec doesn't, then this may just not be something TypeScript should facilitate (since it would be assuming a specific runtime).

[RyanCavanaugh]

@treybrisbane the order is not guaranteed.

What do you think of this?

type Entries<K extends object> = {
    [Key in keyof K]: [Key, K[Key]]
};
function entries<K extends object>(obj: K): Entries<K>[keyof K][] {
    return Object.keys(obj).map(k => [k, obj[k]]) as any;
}

const objFields = entries({ foo: 3, bar: "x" });
for (const f of objFields) {
    if (f[0] === "foo") {
        console.log(f[1].toFixed());
    } else if (f[0] === "bar") {
        console.log(f[1].toLowerCase());
    } else {
        // Only typechecks if f[0] is exhausted
        const n: never = f[1]
    }
}

[zpdDG4gta8XKpMCd]

@RyanCavanaugh when you say things about how order matters it makes me smile, please tell me where in the spec of typescript can i read about the order of overloads on the same method of the same interface coming from different *.d.ts files please, thank you

[RyanCavanaugh]

Each overload is in the order that it appears in each declaration, but the ordering of the declarations is backwards of the source file order. That's it.

[zpdDG4gta8XKpMCd]

and source file order is what? 🎥🍿😎

[RyanCavanaugh]

Quite the tangent from this thread!

[zpdDG4gta8XKpMCd]

you people did it one time, you can do it again, order is order

[krryan]

@RyanCavanaugh OK, a more concrete example. We have a very-large discriminated union that has to get “handled,” which in this case means there needs to be a particular mapping from that union to another. I wrote a factory to build up these handlers, because we were having a lot of trouble with their size, repetition, and occasional differences here and there that were difficult to track (and more difficult to update).

And, of course, I wanted to test this factory as well as anything built with it. That came with the problem that there was no good way to create the basic test that just runs through every member of the union, to make sure everything is getting “captured” correctly.

This is a heavily abbreviated version of something similar to that system.

// making up a fake discriminated union
declare type FooData;
interface Foo { kind: 'foo'; data: FooData; }
declare const foo: Foo;

declare type BarData;
interface Bar { kind: 'bar'; data: BarData; }
declare const bar: Bar;

declare type BazData;
interface Baz { kind: 'baz'; data: BazData; }
declare const baz: Baz;

type DiscriminatedUnion = Foo | Bar | Baz;

// our test case of just "everything"
const eachThingInTheUnion: tupleof DiscriminatedUnion = [foo, bar, baz];

// the factory is more complex than this, but I believe it gives the idea
interface HandlerFactory<Out> {
    // many .handle calls have manually-hard-coded generic arguments
    // as inference doesn't work for whatever reason
    handle: <SomeIn extends DiscriminatedUnion, NewOut>(handler: (value: SomeIn) => NewOut) => HandlerFactory<Out | NewOut>;
    build: () => (value: DiscriminatedUnion) => Out;
}
declare function buildHandler<Out>(defaultHandling: (value: DiscriminatedUnion) => Out): HandlerFactory<Out>;

// Test the handlers built by the factory.
// Notably there are at least a few cases, either due to special circumstances
// or simple legacy code where the handler is NOT built by the factory,
// but is manually created. Still want to be able to test them here.
function testSomeHandler<Out>(
    description: string,
    handle: (value: DiscriminatedUnion) => Out,
    everyOut: tupleof Out,
    areOutsEqual: (one: Out, another: Out) => boolean,
): void {
    // Jasmine test
    describe(description, () => it('Handles all kinds.', () => {
        const results = eachThingInTheUnion.map(handle);
        results.forEach(result => expect(
            everyOut.find(out => areOutsEqual(out, result))
        ).toNotBe(undefined));
        everyOut.forEach(out => expect(
            results.find(result => areOutsEqual(out, result))
        ).toNotBe(undefined));
    }));
}

Since all I want to do with the “tuples” is iterate over them and then check for the presence of each object in one in the other (and vice versa), the actual order in which they appear doesn’t matter to me. I would be equally happy to have tupleof not produce a tuple at all, as long as it produces a collection I can iterate over and search through that is guaranteed to have one (ideally, exactly one) of each thing in the union.

[RyanCavanaugh]

guaranteed to have one (ideally, exactly one) of each thing in the union

This is a bit awkward, but isn't order-dependent:

declare type FooData = number;
interface Foo { kind: 'foo'; data: FooData; }
declare const foo: Foo;

declare type BarData = string;
interface Bar { kind: 'bar'; data: BarData; }
declare const bar: Bar;

declare type BazData = boolean;
interface Baz { kind: 'baz'; data: BazData; }
declare const baz: Baz;

type DiscriminatedUnion = Foo | Bar | Baz;

type ExactMatch<Union, Arr> = Union[] extends Arr ? Arr extends Union[] ? Arr : never : never;

function testHasAll<T>() {
  return function <U>(arg: ExactMatch<T, U>) {

  }
}

// OK
const MyGoodArr = [foo, bar, baz];
testHasAll<DiscriminatedUnion>()(MyGoodArr);

const MyBadArr = [foo, baz];
// Error
testHasAll<DiscriminatedUnion>()(MyBadArr);

[treybrisbane]

@RyanCavanaugh

@treybrisbane the order is not guaranteed.

What do you think of this?

Yeah, what you did there is basically what I've already done. 😃

I think that if the ES spec doesn't guarantee ordering of object entries (which is fair enough), then I consider converting an object type to an in-order tuple of entries to be a fundamentally invalid operation.

I clearly need to find a different approach!

[treybrisbane]

For what it's worth, here's an (arguably) simpler version of what @ShanonJackson posted above:

type Head<T extends any[]> = T extends [infer U, ...unknown[]] ? U : never

type Tail<T extends any[]> =
    T extends any[] ? ((...args: T) => never) extends ((a: any, ...args: infer R) => never) ? R : never : never

type Cons<T extends any[], H> = ((h: H, ...t: T) => any) extends ((...r: infer R) => any) ? R : never;

interface Reduction<Base, In> {
  0: Base
  1: In
}

type UnionReduce<U, R extends Reduction<any, any>> = R[[U] extends [never] ? 0 : 1];

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

type UnionToFunctionOverloads<U> = UnionToIntersection<U extends any ? (f: U) => void : never>;

type UnionPop<U> = UnionToFunctionOverloads<U> extends ((a: infer A) => void) ? A : never;

interface UnionToTupleRec<T extends any[], U>
    extends Reduction<T, UnionReduce<Exclude<U, UnionPop<U>>, UnionToTupleRec<Cons<T, UnionPop<U>>, Exclude<U, UnionPop<U>>>>> { }

type UnionToTuple<U> =
    UnionReduce<U, UnionToTupleRec<[], U>> extends infer T ? T extends any[] ? T : never : never; 

// -----------------------------------------------------------------------------

interface Person {
    firstName: string;
    lastName: string;
    dob: Date;
    hasCats: false;
}

const keysOfPerson: UnionToTuple<keyof Person> = ["firstName", "lastName", "dob", "hasCats"];

It basically works by (ab)using the fact that type-level pattern matching will only infer the type of the last overload when given a set of function overloads.

It's probably not a behavior we should be relying on, tbh. 😝

[krryan]

@RyanCavanaugh Appreciated, that is useful—but as you say, it is pretty awkward. I can even more it purely to the type domain:

const testGood = [foo, bar, baz];
const testedGood: ExactMatch<DiscriminatedUnion, typeof testGood> = testGood;

const testBad = [foo, bar];
const testedBad: ExactMatch<DiscriminatedUnion, typeof testBad> = testBad;

but this is still pretty awkward.

Anyway, another thing that occurs to me that would improve this work-around, or (probably) any workaround, would be a way to get the number of options in a union. This gets awkward in the case of union members that aren’t mutually exclusive (e.g. type A = { foo: number; }; type B = A & { bar: number; }; type U = A | B;—should the result here be 1 or 2? unclear.), but I think defining such a thing as being the number of mutually-exclusive options in a union would be the right call (so the answer for U would be 1). That can probably be added on to my large “it’d be great if Typescript recognized when all members of a union are mutually exclusive and leveraged that fact” wishlist, though, I guess.

[KiaraGrouwstra]

Anyway, another thing that occurs to me that would improve this work-around, or (probably) any workaround, would be a way to get the number of options in a union.

If the above UnionToTuple implementations work (for string literals?), get the tuple then get the length off that using ['length']? Or did you need the length first?

I'm just trying to paste these snippets into TS Playground now, but it complains about everything so I guess it must be quite behind. :neutral_face:

[treybrisbane]

@tycho01 I tested my above code on the official TS playground. Tried again just now and can confirm that it works. 😃

[KiaraGrouwstra]

I forgot why I couldn't just use mapped types, but here's a failed attempt to mimic mapped types by iteration with the above UnionToTuple, using the operation T -> Array<T> as a toy example (where I'd really like to have a function type call instead):

type NumberToString = { [i: number]: string; 0: '0', 1: '1', 2: '2', 3: '3', 4: '4', 5: '5', 6: '6', 7: '7', 8: '8', 9: '9', 10: '10', 11: '11', 12: '12', 13: '13', 14: '14', 15: '15', 16: '16', 17: '17', 18: '18', 19: '19', 20: '20', 21: '21', 22: '22', 23: '23', 24: '24', 25: '25', 26: '26', 27: '27', 28: '28', 29: '29', 30: '30', 31: '31', 32: '32', 33: '33', 34: '34', 35: '35', 36: '36', 37: '37', 38: '38', 39: '39', 40: '40', 41: '41', 42: '42', 43: '43', 44: '44', 45: '45', 46: '46', 47: '47', 48: '48', 49: '49', 50: '50', 51: '51', 52: '52', 53: '53', 54: '54', 55: '55', 56: '56', 57: '57', 58: '58', 59: '59', 60: '60', 61: '61', 62: '62', 63: '63', 64: '64', 65: '65', 66: '66', 67: '67', 68: '68', 69: '69', 70: '70', 71: '71', 72: '72', 73: '73', 74: '74', 75: '75', 76: '76', 77: '77', 78: '78', 79: '79', 80: '80', 81: '81', 82: '82', 83: '83', 84: '84', 85: '85', 86: '86', 87: '87', 88: '88', 89: '89', 90: '90', 91: '91', 92: '92', 93: '93', 94: '94', 95: '95', 96: '96', 97: '97', 98: '98', 99: '99', 100: '100', 101: '101', 102: '102', 103: '103', 104: '104', 105: '105', 106: '106', 107: '107', 108: '108', 109: '109', 110: '110', 111: '111', 112: '112', 113: '113', 114: '114', 115: '115', 116: '116', 117: '117', 118: '118', 119: '119', 120: '120', 121: '121', 122: '122', 123: '123', 124: '124', 125: '125', 126: '126', 127: '127', 128: '128', 129: '129', 130: '130', 131: '131', 132: '132', 133: '133', 134: '134', 135: '135', 136: '136', 137: '137', 138: '138', 139: '139', 140: '140', 141: '141', 142: '142', 143: '143', 144: '144', 145: '145', 146: '146', 147: '147', 148: '148', 149: '149', 150: '150', 151: '151', 152: '152', 153: '153', 154: '154', 155: '155', 156: '156', 157: '157', 158: '158', 159: '159', 160: '160', 161: '161', 162: '162', 163: '163', 164: '164', 165: '165', 166: '166', 167: '167', 168: '168', 169: '169', 170: '170', 171: '171', 172: '172', 173: '173', 174: '174', 175: '175', 176: '176', 177: '177', 178: '178', 179: '179', 180: '180', 181: '181', 182: '182', 183: '183', 184: '184', 185: '185', 186: '186', 187: '187', 188: '188', 189: '189', 190: '190', 191: '191', 192: '192', 193: '193', 194: '194', 195: '195', 196: '196', 197: '197', 198: '198', 199: '199', 200: '200', 201: '201', 202: '202', 203: '203', 204: '204', 205: '205', 206: '206', 207: '207', 208: '208', 209: '209', 210: '210', 211: '211', 212: '212', 213: '213', 214: '214', 215: '215', 216: '216', 217: '217', 218: '218', 219: '219', 220: '220', 221: '221', 222: '222', 223: '223', 224: '224', 225: '225', 226: '226', 227: '227', 228: '228', 229: '229', 230: '230', 231: '231', 232: '232', 233: '233', 234: '234', 235: '235', 236: '236', 237: '237', 238: '238', 239: '239', 240: '240', 241: '241', 242: '242', 243: '243', 244: '244', 245: '245', 246: '246', 247: '247', 248: '248', 249: '249', 250: '250', 251: '251', 252: '252', 253: '253', 254: '254', 255: '255' };

type Inc = { [i: number]: number; 0: 1; 1: 2; 2: 3; 3: 4; 4: 5; 5: 6; 6: 7; 7: 8; 8: 9; 9: 10 };

type Dec = { [i: number]: number; 0: -1; 1: 0; 2: 1; 3: 2; 4: 3; 5: 4; 6: 5; 7: 6; 8: 7; 9: 8 };

type TupleHasIndex<
  Arr extends ArrayLike<any>,
  I extends number
> = ({[K in keyof Arr]: '1' } & Array<'0'>)[I];

type UnionHasKey<Union extends string, K extends string> = ({[S in Union]: '1' } & {[k: string]: '0'})[K];

type StringsEqual<
  A extends string,
  B extends string
> = UnionHasKey<A, B>;

type ArrayifyObject<
    Obj,
    Tpl extends ReadonlyArray<any> = UnionToTuple<keyof Obj>,
    Len = Tpl['length'],
    I extends number = 0,
    Acc = {},
    > = {
        0: Acc,
        1: ArrayifyObject<
            Obj,
            Tpl,
            Inc[I],
            Acc & { [P in Tpl[NumberToString[I]]]: Array<Obj[P]> }
        >
    // }[TupleHasIndex<Tpl, I>];
    }[StringsEqual<Len, I>];

It yields me some ... cannot be used to index type .... I dunno how iteration is done anymore these days. :)

[zpdDG4gta8XKpMCd]

🙏 i hope it's just an academic exercise and no one is desperate that bad to use either of these code monsters

[ShanonJackson]

I use these "code monsters" all the time, code type-safety to me is more important than type readability.

[treybrisbane]

@RyanCavanaugh I happened to find this Stack Overflow answer today, which seems to suggest that while for-in and Object.keys don't follow a well-defined order for keys, other operations like Object.getOwnPropertyNames, Object.getOwnPropertySymbols, and Reflect.ownKeys do follow a well-defined order.

Not sure if its worth adding an entire feature for just those operations, but I figure it's relevant enough to post here anyway. 😃

[felixfbecker]

One problem I have is that in React, you often pass-through props with spread syntax, like <Foo {...this.props}/>. However, this can result in a lot of props being forwarded that are actually not on Foo. If Foo is a PureComponent, it will do a comparison of the props with the previous props to determine if it should rerender. But if more props are passed than used, more props are compared and the comparison takes longer. If you pass props like this through every component every component will rerender. The solution to this would be to implement shouldComponentUpdate(), and making sure only actual props are compared:

interface Props {
  a: any
  b: any
}
const propKeys = ['a', 'b']
class Foo extends Component<Props> {
  shouldComponentUpdate(props: Props, prevProps: Props): boolean {
     return isEqual(pick(props, propKeys), pick(prevProps, propKeys))
  }
}

But it is impossible right now to enforce that all props (no more, no less) are compared. It's easy for a dev to add a new prop and forget to add it to shouldComponentUpdate().

I wish I could use something like:

return arePropsEqual(props, prevProps, ['a', 'b'] as const)

which would be defined as:

const arePropsEqual = <P extends object>(props: P, otherProps: P, keys: TupleOf<keyof P>) =>
   isEqual(pick(props, keys), pick(otherProps, keys))

whenever a prop is added or removed, TypeScript would ensure the array is updated too.

[zpdDG4gta8XKpMCd]

there is a way:

const lessProps: LessProps = {...moreProps}; // <-- this should catch it
<MyPureComponent {...lessProps} />

[felixfbecker]

@aleksey-bykov you would have to do that for every single reference to a component, and for every single component in your render(). And there is nothing enforcing that it's done

[zpdDG4gta8XKpMCd]

yes

[RyanCavanaugh]

@felixfbecker you can do this and actually get remarkably good error messages. Version that can be polished a bit:

interface Props {
    a: any
    b: any
}
type Values<T> = T extends { [index: number]: infer E } ? E : never;
type Extra<Desired, Actual> = Exclude<Actual, Desired> extends never ? true : { "extra": Exclude<Actual, Desired> };
type Missing<Desired, Actual> = Exclude<Desired, Actual> extends never ? true : { "missing": Exclude<Desired, Actual> };
type IsCorrect<Props, Array> = Extra<keyof Props, Values<Array>> | Missing<keyof Props, Values<Array>>;

function checkProps<T, U>(props: T, names: U): IsCorrect<T, U> {
    return true as any;
}
function assertTrue(t: true) {}

declare const props: Props;
// OK
assertTrue(checkProps(props, ["a", "b"] as const));
// Error
assertTrue(checkProps(props, ["a", "b", "c"] as const));
// Error
assertTrue(checkProps(props, ["a", "c"] as const));
// Error
assertTrue(checkProps(props, ["a"] as const));

[felixfbecker]

That looks awesome! I am struggling a bit with translating that into the arePropsEqual signature (i.e. having a constraint on the keys parameter that it must be an exhaustive Array<keyof P>). Is that possible?

[zpdDG4gta8XKpMCd]

am i the only one who sees an all so growing need for type domain assertions? (and lack of thereof support from the language?)

problem is:

• there is no way to create a type and throw it away (type domain statement expressions?):

   MustBeCorrect<Props, Array>; // <-- syntax errror

only

  type _ThankGodThisThingWasIndeedCorrect = MustBeCorrect<Props, Array>;

• there is no better way to do so, other than using phantom functions like assertTrue

• there is no wrong type:

type X<T> = T extends Whatever ? true : wrong<`You can't be here, because...`>

i am looking at you @RyanCavanaugh

[RyanCavanaugh]

Here's a fully-evaporating version with only one name leak. I think you could generalize this into a checkable OK/not-OK thing.

interface Props {
    a: any
    b: any
}
type Values<T> = T extends { [index: number]: infer E } ? E : never;
type Extra<Desired, Actual> = Exclude<Actual, Desired> extends never ? { ok: true } : { "extra": Exclude<Actual, Desired> };
type Missing<Desired, Actual> = Exclude<Desired, Actual> extends never ? { ok: true } : { "missing": Exclude<Desired, Actual> };
type IsCorrect<Props, Array> = Extra<keyof Props, Values<Array>> | Missing<keyof Props, Values<Array>>;

const goodProps = ["a", "b"] as const;
const badProps = ["a", "c"] as const;

namespace PropsCheck {
    type Check1 = IsCorrect<Props, typeof goodProps>["ok"];
    type Check2 = IsCorrect<Props, typeof badProps>["ok"];
}

[KiaraGrouwstra]

That example returns them as if they were legitimate return types though right? I think I can see the use-case @aleksey-bykov is getting at.

[fightingcat]

type Overwrite<T, S extends any> = { [P in keyof T]: S[P] };
type TupleUnshift<T extends any[], X> = T extends any ? ((x: X, ...t: T) => void) extends (...t: infer R) => void ? R : never : never;
type TuplePush<T extends any[], X> = T extends any ? Overwrite<TupleUnshift<T, any>, T & { [x: string]: X }> : never;

type UnionToTuple<U> = UnionToTupleRecursively<[], U>;

type UnionToTupleRecursively<T extends any[], U> = {
    1: T;
    0: UnionToTupleRecursively_<T, U, U>;
}[[U] extends [never] ? 1 : 0]

type UnionToTupleRecursively_<T extends any[], U, S> =
    S extends any ? UnionToTupleRecursively<TupleUnshift<T, S> | TuplePush<T, S>, Exclude<U, S>> : never;

let x: UnionToTuple<1 | 2 | 3 | 4> = [1, 2, 3, 4];
let y: UnionToTuple<1 | 2 | 3 | 4> = [4, 3, 2, 1];

Union to all the permutation of tuples, by generating n! unions.....%20extends%20(...t%3A%20infer%20R)%20%3D%3E%20void%20%3F%20R%20%3A%20never%20%3A%20never%3B%0D%0Atype%20TuplePush%3CT%20extends%20any%5B%5D%2C%20X%3E%20%3D%20T%20extends%20any%20%3F%20Overwrite%3CTupleUnshift%3CT%2C%20any%3E%2C%20T%20%26%20%7B%20%5Bx%3A%20string%5D%3A%20X%20%7D%3E%20%3A%20never%3B%0D%0A%0D%0Atype%20UnionToTuple%3CU%3E%20%3D%20UnionToTupleRecursively%3C%5B%5D%2C%20U%3E%3B%0D%0A%0D%0Atype%20UnionToTupleRecursively%3CT%20extends%20any%5B%5D%2C%20U%3E%20%3D%20%7B%0D%0A%20%20%20%201%3A%20T%3B%0D%0A%20%20%20%200%3A%20UnionToTupleRecursively%3CT%2C%20U%2C%20U%3E%3B%0D%0A%7D%5B%5BU%5D%20extends%20%5Bnever%5D%20%3F%201%20%3A%200%5D%0D%0A%0D%0Atype%20UnionToTupleRecursively%3CT%20extends%20any%5B%5D%2C%20U%2C%20S%3E%20%3D%0D%0A%20%20%20%20S%20extends%20any%20%3F%20UnionToTupleRecursively%3CTupleUnshift%3CT%2C%20S%3E%20%7C%20TuplePush%3CT%2C%20S%3E%2C%20Exclude%3CU%2C%20S%3E%3E%20%3A%20never%3B%0D%0A%0D%0Alet%20x%3A%20UnionToTuple%3C1%20%7C%202%20%7C%203%20%7C%204%3E%20%3D%20%5B1%2C%202%2C%203%2C%204%5D%3B%0D%0Alet%20y%3A%20UnionToTuple%3C1%20%7C%202%20%7C%203%20%7C%204%3E%20%3D%20%5B4%2C%203%2C%202%2C%201%5D%3B%0D%0A)

[RyanCavanaugh]

Where's the reaction for "Please don't put that in your project" ? 😅

[RyanCavanaugh]

Lockpicking with types:

// Secret number sequence, do not share
type CombinationLock<T> = T extends [5, 6, 2, 4, 3, 1] ? T : never;

// Sneaky sneak
type Obj = { 1, 2, 3, 4, 5, 6 }
export const k: UnionToTuple<keyof Obj> = null as any;
// Mouseover on q
export const q: CombinationLock<typeof k> = null as any;

[zpdDG4gta8XKpMCd]

this makes my eyes bleed, i am calling the cops

[RyanCavanaugh]

See comments above - this is not happening.

If you find yourself here wishing you had this operation, PLEASE EXPLAIN WHY WITH EXAMPLES, we will help you do something that actually works instead.

[Griffork]

@RyanCavanaugh how do I type the string keys of an enum in enum order? I'm using an enum's keys to dictate object properties and valid values all over the place, I want the abillity to unroll to function arguments as well (in order, with one property name in the enum having different values to the others): Example as asked:

export enum FloorLayers {
    Natural,
    Foundation,
    Insulation,
    Misc,
    Networks,
    Cover
}
function (natural: Ground | null, foundation: Floor | null, insulation: Floor | null, 
        misc: Floor | null, networks?: Network | null, cover: Floor | null) {

I want the ability to add to my enum and have the function's arguments update without having to rewrite the signature, because this will actually be happening a lot for a lot of different functions, to do this I want to store the enum types in a tuple in the same file as the enum, and then when declaring functions I can assign types to them based on whether or not they extend "Natural" or "Networks" that differ to the rest of the types. I can then access the arguments using the order in the enum (because the order is preserved).

All of the tuple types presented above that preserve order are erroring about potentially infinite recursion except fighting cat but I only want one tuple, not all permutations. I'm using VS TS 3.4.

[jituanlin]

type Overwrite<T, S extends any> = { [P in keyof T]: S[P] };
type TupleUnshift<T extends any[], X> = T extends any ? ((x: X, ...t: T) => void) extends (...t: infer R) => void ? R : never : never;
type TuplePush<T extends any[], X> = T extends any ? Overwrite<TupleUnshift<T, any>, T & { [x: string]: X }> : never;

type UnionToTuple<U> = UnionToTupleRecursively<[], U>;

type UnionToTupleRecursively<T extends any[], U> = {
    1: T;
    0: UnionToTupleRecursively_<T, U, U>;
}[[U] extends [never] ? 1 : 0]

type UnionToTupleRecursively_<T extends any[], U, S> =
    S extends any ? UnionToTupleRecursively<TupleUnshift<T, S> | TuplePush<T, S>, Exclude<U, S>> : never;

let x: UnionToTuple<1 | 2 | 3 | 4> = [1, 2, 3, 4];
let y: UnionToTuple<1 | 2 | 3 | 4> = [4, 3, 2, 1];

Union to all the permutation of tuples, by generating n! unions.....%20extends%20(...t%3A%20infer%20R)%20%3D%3E%20void%20%3F%20R%20%3A%20never%20%3A%20never%3B%0D%0Atype%20TuplePush%3CT%20extends%20any%5B%5D%2C%20X%3E%20%3D%20T%20extends%20any%20%3F%20Overwrite%3CTupleUnshift%3CT%2C%20any%3E%2C%20T%20%26%20%7B%20%5Bx%3A%20string%5D%3A%20X%20%7D%3E%20%3A%20never%3B%0D%0A%0D%0Atype%20UnionToTuple%3CU%3E%20%3D%20UnionToTupleRecursively%3C%5B%5D%2C%20U%3E%3B%0D%0A%0D%0Atype%20UnionToTupleRecursively%3CT%20extends%20any%5B%5D%2C%20U%3E%20%3D%20%7B%0D%0A%20%20%20%201%3A%20T%3B%0D%0A%20%20%20%200%3A%20UnionToTupleRecursively%3CT%2C%20U%2C%20U%3E%3B%0D%0A%7D%5B%5BU%5D%20extends%20%5Bnever%5D%20%3F%201%20%3A%200%5D%0D%0A%0D%0Atype%20UnionToTupleRecursively%3CT%20extends%20any%5B%5D%2C%20U%2C%20S%3E%20%3D%0D%0A%20%20%20%20S%20extends%20any%20%3F%20UnionToTupleRecursively%3CTupleUnshift%3CT%2C%20S%3E%20%7C%20TuplePush%3CT%2C%20S%3E%2C%20Exclude%3CU%2C%20S%3E%3E%20%3A%20never%3B%0D%0A%0D%0Alet%20x%3A%20UnionToTuple%3C1%20%7C%202%20%7C%203%20%7C%204%3E%20%3D%20%5B1%2C%202%2C%203%2C%204%5D%3B%0D%0Alet%20y%3A%20UnionToTuple%3C1%20%7C%202%20%7C%203%20%7C%204%3E%20%3D%20%5B4%2C%203%2C%202%2C%201%5D%3B%0D%0A)

Could you provider any explanation? For example, I can understand :

type UnionToTupleRecursively_<T extends any[], U, S> =
    S extends any ? UnionToTupleRecursively<TupleUnshift<T, S> | TuplePush<T, S>, Exclude<U, S>> : never;

Why S extends any is required in there?