New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected type listed in error message #29861

Open
getify opened this Issue Feb 11, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@getify
Copy link

getify commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Author

getify commented Feb 13, 2019

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

This comment has been minimized.

Copy link
Contributor

dragomirtitian commented Feb 13, 2019

@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 getify closed this Feb 13, 2019

@getify

This comment has been minimized.

Copy link
Author

getify commented Feb 13, 2019

My apologies.

@DanielRosenwasser

This comment has been minimized.

Copy link
Member

DanielRosenwasser commented Feb 13, 2019

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

This comment has been minimized.

Copy link
Member

DanielRosenwasser commented Feb 13, 2019

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

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

RyanCavanaugh commented Feb 13, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment