Do not substitute string literals with string when reporting errors

[erheron]

🔍 Search Terms

error box, string literal, type assignability

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Do not coerce string literal types to a "general" string type when checking assignability and reporting errors.

📃 Motivating Example

Given a code like this:

type S = "Literal type";
declare const s: S;

function acceptsNumber(arg: number){}

acceptsNumber(s);

In TS v3.9.7 the last line would trigger an error Argument of type '"Literal type"' is not assignable to parameter of type 'number'. The string literal type would be presented as it is, and we were using it a lot, primarily to craft helpful error messages in some corner cases of conditional types.

However, since TS v4.0.5 the error changes to the following: Argument of type 'string' is not assignable to parameter of type 'number'.. That's a correct error, but we consider it to be less helpful than the previous one.

💻 Use Cases

1. What do you want to use this for?

More helpful error messages in conditional types (e.g. telling programmers that "Hey, you probably did X and Y wrong")

2. What shortcomings exist with current approaches?

Instead of seeing a message in the error box (preview), people have to open the declaration file and understand how the conditional type is constructed

3. What workarounds are you using in the meantime?

Instead of using a string literal with "Error text", using a named type e.g. interface OpenThisError { message: "Error Text" }

[jcalz]

Presumably this request is a workaround for the lack of #23689 / #40468. Or is there a use case that doesn't involve emulating throw types?

[RyanCavanaugh]

The widening from literal to string in the error message is intentional, since it's clearer that the base primitive type itself is wrong.

[erheron]

Thanks for such a quick response folks! ❤️
If that's working as intended, shall we close this issue, or shall we keep this open as an indicator of community interest in #23689?

[typescript-bot]

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