`NoInfer` on second generic parameter doesn't pick up inference from sibling methods

[paoloricciuti]

🔎 Search Terms

noinfer first type argument

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about

⏯ Playground Link

https://tsplay.dev/weGogm

💻 Code

type Something<A extends object = object, B extends object = object> = {
	a(): A;
	b(name: string): B;
	test(something: NoInfer<B>): void;
}

function test<const A extends object = object, const B extends object = object>(something: Something<A, B>) { }

test({
	test(something) {
		// this should a inferred by the return type of b() but it's actually inferred as object
		// if you switch from NoInfer<B> to NoInfer<A> in Something it's correctly inferred from
		// the return type of a();
		something;
	},
	a() {
		return {
			type: "a",
			value: 43,
		};
	},
	b(name) {
		return {
			type: "b",
			something: true,
			name
		}
	},

});

🙁 Actual behavior

The second type argument in this situation is still inferred as object instead of being the return type of b(). More importantly, if I change NoInfer<B> to NoInfer<A> the argument is correctly inferred from the return type of a()

🙂 Expected behavior

It should correctly infer the second generic argument.

Additional information about the issue

No response

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (68%) microsoft/typescript#40796: Infer keyword should work with unused generic type parameter of a superclass
• (67%) microsoft/typescript#60253: NoInfer breaks discriminate union autocomplete
• (67%) microsoft/typescript#60071: NoInfer does not work in function parameters
• (66%) microsoft/typescript#59638: Inconsistent Type Inference in Generic Function
• (66%) microsoft/typescript#60090: Shared generics allow optional value for a required field
• (66%) microsoft/typescript#468: Type inference bug
• (65%) microsoft/typescript#54213: `infer` not returning expected inner type if another inner type is used in the outer type result
• (65%) microsoft/typescript#57883: NoInfer type not being narrowed properly

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

B can’t be inferred here because it is used in a parameter position in the test method. During contextual typing the compiler gathers inferences for each type parameter separately for

1. covariant positions (e.g. a return type) and
2. contravariant positions (e.g. a parameter type).

b supplies only a covariant (lower-bound) candidate for B: the object you return. However NoInfer<B> in test puts the same type parameter naked in a contravariant position. Once a type parameter occurs in both variance positions the inference algorithm deliberately gives up and fixes the type to its constraint (object) to avoid unsoundness. Consequently no specific type is chosen for B and the default object is used.

When you move NoInfer to A, the roles swap: now A is used contravariantly and falls back to object, while B (which appears only covariantly) is inferred from b’s return type. This is exactly the behavior the inference rules prescribe, so the compiler is working as intended.

[jcalz]

(Not sure what this has to do with NoInfer. Inference from something is already impossible since you didn't annotate it. Is there some meaningful difference between the behavior with and without NoInfer that we should be looking at?)

I'd say this is just #47599 and will probably never be supported if you need inference to happen "right to left". Right now the support for this is described in #48538, and if you need the return type of b() to be used with contextual inference for the something parameter, then you need b() to appear earlier in the object literal:

test({
	a() { return { type: "a", value: 43, }; },
	b(name) { return { type: "b", something: true, name } },
	test(something) {
		something;
		// ^? (parameter) something: {  readonly type: "b";  readonly something: true;  readonly name: string; }
	},
});

playground link

[paoloricciuti]

But this doesn't explain why it can infer a()...the situation is literally the same, the method is before the declaration of a and yet, it can infer the value.

It might not be a NoInfer issue and just a generic issue, but this still feels like a bug to me.

[jcalz]

Because a() isn't context-sensitive. It has no parameters to infer. Please read #47599 and #48538