Repository navigation
Computed string literal can't be used as generic argument #58494
Description
🔎 Search Terms
"string literal is not assignable to parameter of type", "generic string literal argument"
🕗 Version & Regression Information
- This changed between versions 5.1.6 and 5.2.2
⏯ Playground Link
💻 Code
function fn<T>(arg: T): T {
return arg;
}
const a = '1';
const b = a + ' 2';
fn(`${b} 3`);🙁 Actual behavior
Argument of type '`${string} 3`' is not assignable to parameter of type '"1 2 3"'.
🙂 Expected behavior
No errors are expected
Additional information about the issue
No response
Activity
fatcerberus commentedon May 10, 2024
That’s bizarre - it’s inferring
T = "1 2 3"from the argument, but then deciding the same argument isn’t assignable to the type it just inferred.jcalz commentedon May 10, 2024
I... what?! Somehow TS is #44905 magically almost kind of happening? What gives?
Playground link
Did #53907 do this somehow?
Andarist commentedon May 10, 2024
The OP's repro is quite bizarre 😱
That was meant to be my guess but - obviously - you are already one step ahead :D
Andarist commentedon May 11, 2024
My PR is definitely related but it's not the whole story. I'll bisect the other bit more later but I wouldn't be surprised if that would point to some other PR of mine 😅
The OP's case changed between 5.1 and 5.2. #53907 was included as part of 5.1 already and it accidentally changed Joe Calzaretta (@jcalz)'s examples and things like this:
Andarist commentedon May 11, 2024
Oh, somehow I misinterpreted some things at first. #53907 was actually included in 5.2 and is responsible for Dzmitry Tolpekin (@DimaIT)'s and Joe Calzaretta (@jcalz)'s issues. It reused the evaluation strategy that was already in place. It was introduced in #50528 and is responsible for the enum example from my post above.
ahejlsberg commentedon May 11, 2024
The issue with #53907 is that it only performs constant evaluation when the criteria for creating a template literal type are not satisfied (i.e. constant evaluation only occurs in situations where the type would otherwise have been
string). That's a bit backwards. We need to first check if the template literal expression can be evaluated as a constant, and, if so, return a string literal type. I will put up a PR that fixes.ahejlsberg commentedon May 11, 2024
Another example of the strangeness:
It definitely doesn't make sense for
dto be a less specific type thanc, and that, combined with the phasing of type inference and argument type checking in the callfn(`${b} 3`), is what causes the issue.Apart from that, it's a bit odd that
bis considered to have typestring, yet the compiler "knows" it has type"1 2"in the evaluation ofc. We may want to consider constant evaluation of+applied to strings, but that's a separate issue.fatcerberus commentedon May 12, 2024
Yeah, that threw me for a loop too. I know TS has a concept of "widening" types where a literal type can be widened to its base primitive type, but this is the first time I've ever seen a "narrowing" type!