Unexpected type listed in error message

[getify]

TypeScript Version: 3.2? (whatever version is currently on the playground)

Search Terms: "error message", "unexpected", "type", "is not assignable to"

Code

var a = 3;
a = "hello";

vs:

var a = 3;
var b = "hello";
a = b;

Expected behavior:

Expect both error messages to say: "Type 'string' is not assignable to type 'number'."

Actual behavior:

The error message in the first snippet says: "Type '"hello"' is not assignable to type 'number'."

The error message for the second snippet correctly says: "Type 'string' is not assignable to type 'number'."

Playground Link:

Unexpected type listed error message: https://www.typescriptlang.org/play/#src=var%20a%20%3D%203%3B%0D%0Aa%20%3D%20%22hello%22%3B

Expected type listed error message: https://www.typescriptlang.org/play/#src=var%20a%20%3D%203%3B%0D%0Avar%20b%20%3D%20%22hello%22%3B%0D%0Aa%20%3D%20b%3B

[getify]

I'm not sure what "working as intended" means. Are you saying that "hello" (including the "s) is a valid type, as the error message implies? It's clearly not.

It really makes no sense to me why TypeScript would, in the second snippet, be able to determine/infer that "hello" is a string type value, so that b should be set as a string variable, but that the same "hello" value doesn't have an inferrable type of string for the purposes of the error message in the first snippet.

It may be that this is a difficult issue or not worth the effort to fix, but I don't understand how "working as intended" is the appropriate label for its triage?

[dragomirtitian]

@getify "hello" is a valid type in typescript. Any literal can also be a type, the concept is called literal types

So when you perform the assignment, the type of "hello" is the string literal type "hello" and thus you get the error.

String literal types get widened to their base type on assignment (except in some cases, for example assignment to const), so when you first assign b = "hello", b will not be typed as the string literal type but rather to string and you get the error you expect.

[getify]

My apologies.

[DanielRosenwasser]

In isRelatedTo, it should be possible to do a secondary check in the presence of a literal type to see if the base primitive type is related to the target. If not, report against the base primitive type.

[DanielRosenwasser]

Worth noting that that workaround won't work when elaborating from the top of a union, but it's likely good enough.™

[RyanCavanaugh]

@getify apologies there, I labelled this issue and then got interrupted while writing a response. Thanks for being patient.