Computed string literal can't be used as generic argument

[DimaIT]

Computed string literal can't be used as generic argument

[Andarist]

The OP's repro is quite bizarre 😱

Did #53907 do this somehow?

That was meant to be my guess but - obviously - you are already one step ahead :D

[fatcerberus]

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]

I... what?! Somehow TS is #44905 magically almost kind of happening? What gives?

const x = "w" + "t" + "f";
// const x: string
const y = `${x}` 
// const y: "wtf"

Playground link

Did #53907 do this somehow?

[Andarist]

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 @jcalz's examples and things like this:

const a = "1";
const b = a + " 2";

enum E {
  A = b, // "1 2", wat
}

[Andarist]

Oh, somehow I misinterpreted some things at first. #53907 was actually included in 5.2 and is responsible for @DimaIT's and @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]

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]

Another example of the strangeness:

const a = '1';                // "1"
const b = a + ' 2';           // string
const c = `${b} 3`;           // "1 2 3"
const d = `${b} 3` as const;  // `${string} 3`

It definitely doesn't make sense for d to be a less specific type than c, and that, combined with the phasing of type inference and argument type checking in the call fn(`${b} 3`), is what causes the issue.

Apart from that, it's a bit odd that b is considered to have type string, yet the compiler "knows" it has type "1 2" in the evaluation of c. We may want to consider constant evaluation of + applied to strings, but that's a separate issue.

[fatcerberus]

Apart from that, it's a bit odd that b is considered to have type string, yet the compiler "knows" it has type "1 2" in the evaluation of c.

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!