Explicitly infer tuple type

Question

Typescript version: 5.1.6

Here is a minimal reconstruction of my problem:

I have a function f which is gonna take an array of C where

declare class C<a = unknown, b = unknown> {
  getA(): a;
  getB(): b;
};

The first generic of C, which is A is going to be an object.

I want to explicitly get the array of C as a tuple in the f

declare function f<T extends any[]>(arr: [...T]): any;

declare const a: C<{ name: string }, []>;
declare const b: C<{ name: string }, []>;

f([a, b])

Hovering on the f we can see exactly what we want.

function f<[C<{
    name: string;
}, []>, C<{
    name: string;
}, []>]>(arr: [C<{
    name: string;
}, []>, C<{
    name: string;
}, []>]): any

The problem comes when I want to wrap the array type with another type, which is going to check if there are duplicate keys on the T.

When I do something like this:

type ExtractObject<I> = I extends C<infer P> ? P : never;
type ExtractObjectFromList<I> = {
  [P in keyof I]: ExtractObject<I[P]>;
};


declare function f<T extends any[]>(arr: HasDuplicateKey<ExtractObjectFromList<[...T]>> extends true ? "Err" : T): any;

declare const a: C<{ name: string }, []>;
declare const b: C<{ name: string }, []>;

f([a, b])

or

declare function f<T extends any[]>(arr: [...T] extends infer P ? HasDuplicateKey<ExtractObjectFromList<P>> extends true ? "err" : P: never): any;

declare const a: C<{ name: string }, []>;
declare const b: C<{ name: string }, []>;

f([a, b])

it is not working correctly since it is losing the tuple type and it is converted to (C<{ name: string }, []>[])[]

I wonder if there is a solution to this without using as const when passing the array, this is part of a library and I want to be backwards compactable.

So the idea is to highlight to display an error message when the keys of the first generic in C has a collision and also ability to do some more checks on top of that

Also this is the HasDuplicateKey type

export type HasDuplicateKey<T> = T extends readonly [infer First, ...infer Rest]
  ? Rest extends readonly [infer Next, ...infer Others]
    ? keyof First extends keyof Next
      ? true
      : HasDuplicateKey<readonly [First, ...Others]>
    : false
  : false;

Does [this approach](https://tsplay.dev/wO2JrW) work for you? If yes, I'll write an answer explaining; If not, what am I missing? — wonderflame, Aug 14 '23 at 15:09
@wonderflame It does not work since it should throw an error, in the example you provide try to remove the first declare of `f` and the calls you are doing should highlight the error, since the objects have dublicate keys. If you do that and hover on `f` you can see: `{name: string}[]` which is the reason we get a wrong output — Hello Hello, Aug 14 '23 at 15:15
This sort of thing is very tricky; the inference is fragile. The only way I know of not to "disturb" the inference for tuples like this is to use a homomorphic mapped type. Like [this approach](https://tsplay.dev/w1a6Gw) for example. Does that meet your needs? If so I'll write up an answer for it; otherwise what doesn't work for you? — jcalz, Aug 14 '23 at 15:56
@jcalz Yes, I think that's what I want, The problem is that I don't have a list of simple objects, Its a list of class which I infer the object, have a look at this other example [here](https://tsplay.dev/WzDAEN), on top of that I have to do some other checks on the object itself, so it is a bit more complicated — Hello Hello, Aug 14 '23 at 20:39
@jcalz I can also do something like this example [here](https://tsplay.dev/wQbVAN), but the problem with this approach is that I am going to lose other generics about the object, I don't know if there is a way around this — Hello Hello, Aug 14 '23 at 21:01
You can't have `declare class C {};` and expect anything to work; empty classes and [unused type parameters](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-doesnt-type-inference-work-on-this-interface-interface-foot--) are not going to infer properly. I can answer the question as asked, or you could [edit] the question with a [mre] that demonstrates the more complicated issue you're having, without introducing unrelated issues like unused type parameters. How would you like to proceed? — jcalz, Aug 14 '23 at 21:18
But you still have `declare class C {};`, which will not work as desired because it has [unused type parameters](unused type parameters). You need `A` and `B` to be *used* somewhere in the structure of `C`, or it's a fool's errand to try to infer anything about `A` or `B` in there. Please resolve this or I can't really do much. — jcalz, Aug 14 '23 at 23:09
So now does [this approach](https://tsplay.dev/mZJ44m) meet your needs? — jcalz, Aug 15 '23 at 21:34
@jcalz That is perfect, would be great if you will answer it so I can mark as correct — Hello Hello, Aug 15 '23 at 22:27
@jcalz There is a problem with that approach, it will fail if you try with this: `declare const a: C<{}, []>;` or `declare const a: C;` — Hello Hello, Aug 15 '23 at 23:28
I don't get it. What "fails" with `C<{}, []>`? I tried it and the behavior looks reasonable to me. And what use is a type like `C`? Are you expecting `never` for some reason? You'll always be able to throw weird types in there and mess things up (`any` will wreak havoc, and `never` will probably do so too) but I'm not sure why that's relevant. At this point my options are: write up my approach and leave it to you to modify it for other situations, or disengage entirely because the scope of the question continues to expand in response. Let me know which one you prefer. — jcalz, Aug 15 '23 at 23:45
@jcalz As you said, you can write up your approach, and I will modify it based on my needs — Hello Hello, Aug 16 '23 at 06:17

jcalz · Accepted Answer · 2023-08-16T21:03:12.313

You're looking to emulate a circular generic constraint function f<T extends F<T>>(arg: T) {} where F<T> is a "validation" type function, where T extends F<T> essentially evaluates to some supertype of T if and only if T is "valid". Sometimes you can actually write such a constraint directly, but often the compiler will complain that it is circular.

There are various approaches to emulating such constraints, but it can be hard to find one that doesn't mess up the compiler's ability to infer T from the argument passed in for arg. It's fragile.

Sometimes you can write function f<T>(arg: F<T>) {} and it works. Sometimes that doesn't work but function f<T>(arg: T & F<T>) {} works. Sometimes that doesn't work but function f<T>(arg: T extends F<T> ? T : F<T>) {} works. And sometimes none of those work; it looks like when T is supposed to be a tuple type and you use a variadic tuple type hint function f<T extends any[]>(arg: [...F<T>]) {} then it often just... breaks.

In such cases you can try rewriting the validation type function F<T> in terms of a a validation type function G<T> that acts on each tuple element individually, so F<T> would be a homomorphic mapped type (see What does "homomorphic mapped type" mean?) of the form {[I in keyof T]: G<T[I]>}. This seems to preserve the inference behavior more or less, but requires that you refactor the check.

For the example as shown here, I'd probably write it like this:

declare function f<T extends C<any, any>[]>(
  arr: [...DeDuplicateKeys<T>]
): T;

type DeDuplicateKeys<T extends C<any, any>[]> =
  { [I in keyof T]: T[I] &
    C<Record<RepeatsAtIndex<Keys<T>, I>, never>, any>
  }

type RepeatsAtIndex<T, I> =
  T[Extract<keyof T, I>] & T[Exclude<keyof T, I>];

type Keys<T extends C<any, any>[]> =
  { [I in `${number}` & keyof T]:
    T[I] extends C<infer A, any> ? keyof A : never
  };

So DeDuplicateKeys<T> is our homomorphic mapped type which applies the check T[I] & C<Record<RepeatsAtIndex<Keys<T>, I>, never>, any> to each tuple element of T at index I.

The way that works is to take T and map it to a new tuple-like type containing just the keys of the A type argument of C<A, B>; that's what Keys<T> does (it's not a real tuple, but has the numeric like indices "0", "1", etc). And then RepeatsAtIndex<Keys<T>, I> will give you just those keys which occur in the Ith element of the tuple which also appear in some other element. The hope is that this will be never. And then Record<RepeatsAtIndex<Keys<T>, I>, never> is an object type with all those repeated keys and a value type of never. If there are any repeated keys at all, this will make an impossible type like {name: never}. Otherwise it will be the permissive empty object type {}. By intersecting with T[I], we will either get just T[I] if it's good, or something impossible if it's bad.

Frankly it's complicated, but your constraint is complicated, because it acts on one type argument of a generic type inside the tuple elements.

Anyway, let's test it out:

declare const a: C<{ name: string }, []>;
declare const b: C<{ name: string }, []>;
declare const c: C<{ age: number }>;
f([a, c]); // okay
// function f<[C<{ name: string; }, []>, C<{ age: number; }, unknown>]>(⋯): ⋯;
f([b, c]); // okay
// function f<[C<{ name: string; }, []>, C<{ age: number; }, unknown>]>(⋯): ⋯;
f([a, b, c]); // error
// ~  ~ <-- types of property "name" are incompatible
// function f<[
//   C<{ name: string }, []>, C<{ name: string }, []>, C<{ age: number }, unknown>
// ]>(⋯): ⋯;

Looks like what you wanted. The T type argument is inferred in each case to be the correct tuple type, and valid combinations are accepted, while invalid combinations are rejected.

Note that there may well be edge cases not accounted for here, but the general approach I'd take here would still be to try to write a validation type function out of a homomorphic mapped type.

Playground link to code

Explicitly infer tuple type

1 Answers1