Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type manipulations: union to tuple #13298

Closed
krryan opened this issue Jan 5, 2017 · 61 comments
Closed

Type manipulations: union to tuple #13298

krryan opened this issue Jan 5, 2017 · 61 comments

Comments

@krryan
Copy link

@krryan krryan commented Jan 5, 2017

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

This comment has been minimized.

Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Jan 5, 2017

functionof would not hurt either: #12265

@aleclarson

This comment has been minimized.

Copy link

@aleclarson aleclarson commented Sep 21, 2018

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

This comment has been minimized.

Copy link
Author

@krryan krryan commented Sep 21, 2018

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

This comment has been minimized.

Copy link

@ShanonJackson ShanonJackson commented Feb 27, 2019

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

@ShanonJackson

This comment has been minimized.

Copy link

@ShanonJackson ShanonJackson commented Feb 28, 2019

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 krryan changed the title Type manipulations: union to tuple, tuple to union Type manipulations: union to tuple Feb 28, 2019
@krryan

This comment has been minimized.

Copy link
Author

@krryan krryan commented Feb 28, 2019

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

This comment has been minimized.

Copy link

@aleclarson aleclarson commented Feb 28, 2019

@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

This comment has been minimized.

Copy link
Author

@krryan krryan commented Feb 28, 2019

@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

This comment has been minimized.

Copy link
Contributor

@dragomirtitian dragomirtitian commented Feb 28, 2019

@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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Feb 28, 2019

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

This comment has been minimized.

Copy link
Author

@krryan krryan commented Feb 28, 2019

@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

This comment has been minimized.

Copy link
Contributor

@dragomirtitian dragomirtitian commented Feb 28, 2019

@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

This comment has been minimized.

Copy link

@ShanonJackson ShanonJackson commented Feb 28, 2019

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

This comment has been minimized.

Copy link
Author

@krryan krryan commented Feb 28, 2019

@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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Feb 28, 2019

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.

@tycho01

This comment has been minimized.

Copy link
Contributor

@tycho01 tycho01 commented Feb 28, 2019

@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. 😐

@treybrisbane

This comment has been minimized.

Copy link

@treybrisbane treybrisbane commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Mar 1, 2019

@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

This comment has been minimized.

Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Mar 1, 2019

@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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Mar 1, 2019

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

This comment has been minimized.

Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Mar 1, 2019

and source file order is what? 🎥🍿😎

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Mar 1, 2019

Quite the tangent from this thread!

@zpdDG4gta8XKpMCd

This comment has been minimized.

Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Mar 1, 2019

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

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Apr 3, 2019

@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

This comment has been minimized.

Copy link

@felixfbecker felixfbecker commented Apr 3, 2019

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

This comment has been minimized.

Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Apr 3, 2019

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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Apr 3, 2019

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"];
}
@tycho01

This comment has been minimized.

Copy link
Contributor

@tycho01 tycho01 commented Apr 4, 2019

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

This comment has been minimized.

Copy link

@fightingcat fightingcat commented Apr 11, 2019

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.....

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Apr 11, 2019

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

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Apr 11, 2019

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 comment has been minimized.

Copy link

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd commented Apr 11, 2019

this makes my eyes bleed, i am calling the cops

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented May 17, 2019

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

This comment has been minimized.

Copy link

@Griffork Griffork commented Jun 8, 2019

@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

This comment has been minimized.

Copy link

@jituanlin jituanlin commented Jul 3, 2019

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.....

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?

@fightingcat

This comment has been minimized.

Copy link

@fightingcat fightingcat commented Jul 11, 2019

Conditional types in which the checked type is a naked type parameter are called distributive conditional types. Distributive conditional types are automatically distributed over union types during instantiation. For example, an instantiation of T extends U ? X : Y with the type argument A | B | C for T is resolved as (A extends U ? X : Y) | (B extends U ? X : Y) | (C extends U ? X : Y).

@jituanlin This is called distributive condition types, has been explained here.

@hediet

This comment has been minimized.

Copy link

@hediet hediet commented Jul 22, 2019

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.....

@fightingcat Just for reference, there is a cleaner way to destructure a tuple:

export type DestructureTuple<T extends any[]> = T extends []
	? false
	: ((...tuple: T) => void) extends ((
			first: infer TFirst,
			...rest: infer TRest
	  ) => void)
	? { first: TFirst; rest: TRest }
	: false;
@fightingcat

This comment has been minimized.

Copy link

@fightingcat fightingcat commented Jul 22, 2019

@hediet But there is no use of destructuring in this demonstration...

@Griffork

This comment has been minimized.

Copy link

@Griffork Griffork commented Jul 22, 2019

If this is never going to be made into a keyword, can someone make and maintain a library for it?
I'm loathe to include typing code that I don't understand into my project in case it breaks in an update (I use all the strict flags) and as fluent in typescript's types as I claim to be, I can't get my head around that mess of typings even after spending hours picking it apart.

I'm truly amazed that this isn't a candidate for inclusion given how often I've needed it, whereas things like Partial are.

@dragomirtitian

This comment has been minimized.

Copy link
Contributor

@dragomirtitian dragomirtitian commented Jul 23, 2019

@Griffork The problem here is multi-fold and has been explained in this thread, some highlights:

  1. Conceptually unions are un-ordered, tuples are ordered
  2. The current implementation does not maintain a consistent union ordering and changing this would be difficult

Partial is a simple application of mapped types, it's easy to include that in the default library.

All variations of tuple to union suffer from issues. They all use unsupported recursive types aliases which is already a red flag.

The version that generates a single tuple IS NOT STABLE BETWEEN BUILDS. Small code changes in completely unrelated code can easily make the compiler create the union in a different order and thus the tuple will be in a different order and this will break your code seemingly at random.

The version that generates all possible permutations is a performance trap. For a small number of union constituents it will probably work decently (willing to be wrong here) but consider what generating all permutations means for a union with 10 constituents. The number of all permutations is 10! (3628800). That is a huge number of types from a relatively small union. Adding such a type would need to come with the warning use for up to a maximum of 8 which would just be bad.

Given all these issues I would run as fast as I can from any library delivering a type called UnionToTuple. Any such library would be hiding major problems from its consumers and would be behaving irresponsibly IMO.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Jul 23, 2019

I wish I could 👍 @dragomirtitian's comment more than once

@AnyhowStep

This comment has been minimized.

Copy link
Contributor

@AnyhowStep AnyhowStep commented Jul 26, 2019

I would like to take this one step further and ask for an RNG type (because lulz).
The RNG<U> type should take a union of types and return a random one.

//Mouseover this
type a = RNG<1|2|3|4>;
//Mouseover this
type b = RNG<1|2|3|4>;

Every time you mouse over it, it should give you a different result.
Every time you build, it gives you a different result.
Every time it resolves, it gives you a different result.

I wouldn't be surprised if a and b have different types most of the time.

Please implement this /s

@AnyhowStep

This comment has been minimized.

Copy link
Contributor

@AnyhowStep AnyhowStep commented Jul 26, 2019

Simpler version of the permutations approach,

type PushFront<TailT extends any[], HeadT> = (
  ((head : HeadT, ...tail : TailT) => void) extends ((...arr : infer ArrT) => void) ?
  ArrT :
  never
);
type CalculatePermutations<U extends string, ResultT extends any[]=[]> = (
    {
        [k in U] : (
            Exclude<U, k> extends never ?
            PushFront<ResultT, k> :
            CalculatePermutations<Exclude<U, k>, PushFront<ResultT, k>>
        )
    }[U]
);

type elements =|"z"|"y"|"x"|"a"
//type p = ["a", "x", "y", "z"] | ["x", "a", "y", "z"] | ["a", "y", "x", "z"] | ["y", "a", "x", "z"] | ["x", "y", "a", "z"] | ["y", "x", "a", "z"] | ["a", "x", "z", "y"] | ["x", "a", "z", "y"] | ... 15 more ... | [...]
type p = CalculatePermutations<elements>

Playground

Don't try it with 10 elements.

@danieldietrich

This comment has been minimized.

Copy link

@danieldietrich danieldietrich commented Sep 15, 2019

Hi @RyanCavanaugh, I could really use your help with this one.

My use case is recursively merging objects. A real world use-case would be to merge OpenAPI specifications (denoted in JSON) of multiple Microservices in order to produce a consolidated API specification for an API Gateway (on top of the Microservices).

I've create such a merge function, published here.

The merge algorithm is roughly as follows. Given non-null and non-undefined input objects,

  • objects are merged by recursively merging the values of same keys
  • arrays are merged by concatenating them
  • otherwise (value1, value2) are merged by overwriting value1 with value2 if value2 isn't undefined, otherwise value1

Example:

// = {a: "2", b: [1, "2"]}
const o = mergeObjects(
    {a: 1, b: [1]},
    {a: "2", b: ["2"]},
    null,
    undefined
);

I managed to infer the result type by

  • statically calculating the union of all objects
  • removing undefined object property values

The signature looks like this:

function mergeObjects<T extends Obj>(...objects: T[]): Merged<T>

Currently, the inferred type Merged of the the example above is:

const o: {
    a: number;
    b: number[];
} | {
    a: string;
    b: string[];
}

Problem:

// infers to number | string
const x = o.a

// infers to number[] | string[]
const x = o.b

Expected result:

// infers to string (<--- last element of the union number | string)
const x = o.a

// infers to Array<number | string> resp. (number | string)[]
const x = o.b

Missing parts:

// (T extends Array<infer U> | Array<infer V> | ...)
//   ? Array<U | V | ...>
//   : ...
type ZipArrayUnion<T> = T; // TODO: ???

// (T extends U | V) ? V : ...
type LastUnionElement<T> =
    // TODO: ??? add case to select last union element
    T extends JSONObject ? { [K in keyof T]: LastUnionElement<T[K]> } :
    T;

I came here because I thought the last element of a union could be statically calculated using tuples.

Complete types:

// Type of input objects
type Obj = JSONObject | null | undefined;

// Output type = merged inputs
type Merged<T extends Obj> = LastUnionElement<ZipArrayUnion<NoUndefinedField<NonNullable<T>>>>;

// Removes fields with undefined values
type NoUndefinedField<T> =
    T extends JSONArray ? T :
    T extends JSONObject ? { [P in keyof T]-?: NoUndefinedField<NotUndefined<T[P]>> } :
    T;

// Does not permit undefined
type NotUndefined<T> = T extends undefined ? never : T;

// (T extends Array<infer U> | Array<infer V> | ...)
//   ? Array<U | V | ...>
//   : ...
type ZipArrayUnion<T> = T; // TODO: ???

// (T extends U | V) ? V : ...
type LastUnionElement<T> =
    // TODO: ??? add case to select last union element
    T extends JSONObject ? { [K in keyof T]: LastUnionElement<T[K]> } :
    T;

// A recursive JSON definition, permitsundefined
type JSONValue =
    | string
    | number
    | boolean
    | null
    | undefined
    | JSONObject
    | JSONArray;

interface JSONObject {
    [x: string]: JSONValue;
}

interface JSONArray extends Array<JSONValue> { }

TypeScript's type system is said to be Turing complete, so theoretically it must be possible.

I would be glad to hear some feedback or comments!

Thanks,

Daniel


Update

Looking at lib.es2015.core.d.ts shows, that Object.assign does an intersection & instead of a union |. Projected to my case, mergeObjects currently infers a union T of input objects. I just need to turn that into an intersection when calculating the result type:

type Obj = Record<string, unknown>;

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

function mergeObjects<T extends Obj | null | undefined>(...objects: T[]): Merged<NonNullable<T>>

That way, merging {a: number} and {a: string} will lead to {a: number & string}, which is effectively {a: never}. On the type level, that makes sense to me.

Note: lib.es2015.core.d.ts currently does not seem to be that accurate for > 4 input parameters.

@AnyhowStep

This comment has been minimized.

Copy link
Contributor

@AnyhowStep AnyhowStep commented Sep 15, 2019

You don't need union to tuple for this.

Also, ask on stack overflow or gitter


Also, you want mergeObjects to infer a tuple type for its input. And you'll want a recursive type alias to calculate the output.

@treybrisbane

This comment has been minimized.

Copy link

@treybrisbane treybrisbane commented Oct 19, 2019

Just for fun, I decided to see how much simpler the union -> tuple implementation would be with the recent improvements around recursive type aliases. Turns out, noticeably! 😄

type TupleHead<Tuple extends any[]> =
    Tuple extends [infer HeadElement, ...unknown[]] ? HeadElement : never;

type TupleTail<Tuple extends any[]> =
    ((...args: Tuple) => never) extends ((a: any, ...args: infer TailElements) => never)
    ? TailElements
    : never;

type TuplePrepend<Tuple extends any[], NewElement> =
    ((h: NewElement, ...t: Tuple) => any) extends ((...r: infer ResultTuple) => any) ? ResultTuple : never;

type Consumer<Value> = (value: Value) => void;

type IntersectionFromUnion<Union> =
    (Union extends any ? Consumer<Union> : never) extends (Consumer<infer ResultIntersection>)
    ? ResultIntersection
    : never;

type OverloadedConsumerFromUnion<Union> = IntersectionFromUnion<Union extends any ? Consumer<Union> : never>;

type UnionLast<Union> = OverloadedConsumerFromUnion<Union> extends ((a: infer A) => void) ? A : never;

type UnionExcludingLast<Union> = Exclude<Union, UnionLast<Union>>;

type TupleFromUnionRec<RemainingUnion, CurrentTuple extends any[]> =
    [RemainingUnion] extends [never]
    ? { result: CurrentTuple }
    : { result: TupleFromUnionRec<UnionExcludingLast<RemainingUnion>, TuplePrepend<CurrentTuple, UnionLast<RemainingUnion>>>['result'] };

export type TupleFromUnion<Union> = TupleFromUnionRec<Union, []>['result'];

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

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

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

Playground link

(Something, something, probably don't use this in your projects, something)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.