Inference does not extend to generics of types, causing widened covariant types, and errors for contravariant types

[erikbrinkman]

Bug Report

When a generic type is constrained by another generic type, the inference doesn't extend to the second generic type unless it is explicitly included in the function signature. In short, <T, U extends I<T>>(_: U) will always infer unknown for T. I couldn't find any issues referencing this, but the behavior has to be known about. For most types, e.g. covariant ones, this isn't strictly incorrect, it just produces a wider type than a user might expect. However, for contravariant types, this will actually caused a rejection of valid code. Both instances can be "fixed" by manually specifying both types in the signature, e.g. <T, U extends I<T>>(_: U & I<T>) but this is clunky and may not be obvious to some people (i.e. me).

I could believe that this is also a design limitation, but given the semantics of extends, I would think it's possible to "insert" these extra intersections whenever a type is constrained by a generic. Most times it will be meaningless, but in this instance it will allow inference to pick up the appropriate type.

🔎 Search Terms

inference, bound, constraint

🕗 Version & Regression Information

• This is the behavior in every version I tried (3.3, 4.2, beta, nightly), and I reviewed the FAQ for entries about ________ (I'm not sure what should go in this blank, but I did not find any references in the FAQ)

⏯ Playground Link

Playground link with relevant code

💻 Code

Admittedly, but examples are a little contrived, but I have run into them in actual code, where I need references to both types.

Covariant example

interface Covariant<T> {
    val: T
}

declare function covariantSimple<T, C extends Covariant<T>>(inp: C): { inp: C, inner: T };
covariantSimple({ val: { foo: 5 } }).inner.foo;
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ object is unknown
// but object should / would normally be inferred to be of type { foo: number }

// manually specifying the intersection in the type tells typescript how to do the inference
declare function covariantIntersection<T, C extends Covariant<T>>(inp: C & Covariant<T>): { inp: C, inner: T };
covariantIntersection({ val: { foo: 5 } }).inner.foo;  // no error

Contravariant example

interface Contravariant<T> {
    (val: T): boolean;
}

declare function contravariantSimple<T, C extends Contravariant<T>>(inp: C): C;
contravariantSimple(({ val }: { val: boolean }) => val);
//                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// Argument of type '...' is not assignable to parameter of type 'Contravariant<unknown>'
// same error, but since the type is contravariant, failure to infer a narrower type for T causes a type error

// like before, manually specifying the intersection allows typescript to infer properly
declare function contravariantIntersection<T, C extends Contravariant<T>>(inp: C & Contravariant<T>): C;
contravariantIntersection(({ val }: { val: boolean }) => val); // no error

🙁 Actual behavior

When a generic type is constrained by another generic type, the inference doesn't extend to the second generic type unless it is explicitly included in the signature.

🙂 Expected behavior

The inference magically works!

[RyanCavanaugh]

This is an intentional design of constraints; we tried doing this at one point and it actively made a bunch of stuff worse.

I've never seen a case where the function couldn't be rewritten in terms of fewer type parameters without loss of generality, e.g.

function covariantSimple<T extends Covariant<unknown>>(inp: T): { inp: T, inner: T["val"] } {
    return { inp, inner: inp.val };
}

covariantSimple({ val: { foo: 5 } }).inner.foo;

You should really never have two type parameters without two values; this is either a soundness hole in the implied body of the function or an oversight in the signature.

contravariantSimple's compilation failure is a legitimate error because there's no way for the function to correctly call an arbitrary thing passed to it.

[erikbrinkman]

I can totally believe that it's not worth doing, or that implementing it is more complicated than these simple extensions. However, I still think there are important differences to at least how these are carried out currently.

For simplicity, let's talk only about the contravariant case. I understand why contravariantSimple is erring, but it's only because typescript is not inferring a value for T, because there does exist a valid signature where T is inferred, as evidenced by contravariantIntersection. However imagine that T is not entirely unbound, but instead constrained to extend another type, say S, and somehow the return type needed to include the inferred T (for this purpose I'm going to specify that as the return type, even though it doesn't make a lot of sense; also note that in most cases you might not have to use conditional types to extract T, although it arguably makes it simpler for complex types). My definition of the declaration would now look like:

declare function contravariantExtends<C extends Contravariant<never>>(inp: C): C extends Contravarant<infer T> ? T extends S ? T : never : never;

I would argue that the intent of this is less clear than

declare function contravariantIntersection<T extends S, C extends Contravariant<T>>(inp: C & Contravariant<T>): T;

even with the intersection, although "ideally" (in the sense of this issue) without it. More importantly, they're different in that covariantExtends will return never for "invalid" inputs, versus contravariantIntersection will error. Also, to use T inside the function body is very simple with contravariantIntersection, but contravarnatExtends will likely need a wrapper type to use T effectively in the implementation. There's also likely a difference in the way they handle union types. I'm sure that those could be addressed, but they aren't addressed with the way I wrote it.

If I'm missing something obvious, then this is almost certainly irrelevant. However given your note about implementation I'm going to close it anyway, because it is very reasonable to think this isn't worth doing.

[erikbrinkman]

Also, this union trick is especially useful with Invariant types e.g.

interface Invariant<T> {
    (inp: T): T;
}

Some examples are in this playground link, but essentially since it's invariant with respect to T, it's not possible to set some default parameter to make it the most general. The only way to make it work with the single parameter version is to define some super type which can be filled with generic constraints, and then narrow the return type so that it's never if the input doesn't actually extend the invariant type (see playground).

Also, using the invariant type will be difficult to use in any implements, because the input and return types don't align, e.g. if they needed to be chained, or the constraint was useful in the definition. All this is just to say that IMO invariantSimple is the reasonable way to implement this, but it doesn't work for the complexity described. For a lot of reasons, the invariantIntersection is probably the best way to implement it that works, although it still feels clunky. And the way recommended is maybe feasible, but produces sub-par results, and would be hard to implement in many situations.