Skip to content

Do not substitute string literals with string when reporting errorsΒ #56844

Closed as not planned
@erheron

Description

@erheron

πŸ” Search Terms

error box, string literal, type assignability

βœ… Viability Checklist

⭐ 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" }

Metadata

Metadata

Assignees

No one assigned

    Labels

    Working as IntendedThe behavior described is the intended behavior; this is not a bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions