TS3.6/3.7 regression: template arguments used in unions no longer resolve/narrow

[mprobst]

TypeScript Version: 3.7.1-rc

Search Terms: template argument union

Code

declare class Data {
  string<T>(defaultValue?: string|T): string|T;
}

declare const str: string|undefined;
const x = new Data().string(str);

Expected behavior:

I'd argue string, at least that's what the user intended here.

Actual behavior:

In TypeScript version:

• 3.5, typeof x === string
• 3.6, typeof x === unknown
• 3.7, typeof x === string|undefined

Playground Link: n/a

[mprobst]

I presume this is an intentional change (?) but I could find an existing issue.

[AlCalzone]

IMO the inferred type is the only logical one here. You pass a variable of type string|undefined to an argument expecting string|T, so T is inferred as undefined. The method returns string|T, so I expect the return type to be string|undefined.

[mprobst]

@AlCalzone note the ? in defaultValue?. The parameter is optional, so its real type is string|T|undefined. We're passing string|undefined into string|undefined|T, so T should/could be never, I guess?

[RyanCavanaugh]

I think this is a bug; undefined should indeed be part of the union for the purposes of inference. So T = never and x should be string. Maybe this is the smallest code snippet that can produce different behavior in 4 consecutive versions of TypeScript 😶

[fatcerberus]

If there's no way to infer T then shouldn't it default to its constraint of unknown (the TS 3.6 behavior), rather than becoming never?

[ahejlsberg]

The core issue here is what, if anything, to infer for T when inferring from a source type X to a target type X | T?

1. Make no inference. Problem here is if we make no other inferences for T, we'll end up with the constraint, which typically is the default unknown. That's a terrible outcome because it is less specific than what we started with.
2. Infer never. This doesn't work if we're inferring for a function that returns just T since it would suddenly imply the function never returns.
3. Infer X. This is pretty much the only meaningful thing to do.

In 3.5 we'd pick option 3 for a non-union type X and option 2 for a union type X. That was obviously inconsistent. In 3.6 we started out with option 1 and then, prompted by issues, switched to option 3 in the 3.6.3 release. Nothing has changed in 3.7 and we're still doing option 3. I continue to think this is the only meaningful option.

[ahejlsberg]

See #32460, #32558, and #33252 for more context.

[fatcerberus]

That's a terrible outcome because it is less specific than what we started with.

Maybe, but if this is really the benchmark: doesn't the same thing already happen any time you infer from a source Y to target X | T? X | Y is necessarily less specific than Y.

[ahejlsberg]

Maybe, but if this is really the benchmark: doesn't the same thing already happen any time you infer from a source Y to target X | T? X | Y is necessarily less specific than Y.

Yes, but there's no reason an inference from X to X | T should produce a final type that is less specific than X. For example, when inferring from string to string | T, if we infer unknown then the final type ends up being unknown, meaning you could pass an argument of any type.

[fatcerberus]

I see what you're saying, but from a type-theoretical standpoint I view it as the same kind of question as "Given an empty array [], what is the T in Array<T>"--and in such case we can say T is anything we want because an empty array is always a valid input regardless of what T is.

[nreid260]

In the Closure compiler we would arrive at the same inference at TS3.7 (`string|undefined') which I believe to be the correct one.

Effectively the question being asked is "what should T be inferred as?". When the inference is against a union containing T the only consistent thing to do is to distribute over all the union elements. That is T is inferred to be the entire type of the passed argument.

As a human, in this case, you probably imagine some kind of "type subtraction" where first we remove the common elements of the argument and parameter unions, before inferring T. However, for cases that don't involve finite types, "subtraction" is not well defined. In this example even, what's the correct result if str was 'foo'|undefined?

[fatcerberus]

I point back to my empty array example: Given an empty array, what is the T in T[]? And the question itself is nonsensical because no example of T exists; however, practically speaking, we can say T is anything we want without introducing any unsoundness.

[ahejlsberg]

When someone writes string | T it is a strong indication that T is intended to be disjoint with string. For this reason unknown is a bad inference as it encompasses string. And never is a bad inference for the reason previously outlined. That leaves string, which is what we currently infer.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.