Skip to content

Support Intellisense for string/number literals in a widened union #33471

Description

@orta

Search Terms

autocomplete union wide

Suggestion

In both #28743 and #28743 they were correctly closed for being correctly widened to a string.

Use Cases

I'd like to pitch that this is useful only from the IDE experience, and that's purely where the value comes in from. The widening to a string makes sense, however allowing this lets you declare an API where you would like to allow any input, but there are preferred options.

Examples

// @errors: 2345 2345
type ErrorStatus = 'not_found' | 'failed' | 'parse_error'

declare function fail(status: ErrorStatus): any

fail("not")
//       ^|

declare function failString(status: ErrorStatus | string): any

failString("not")
//             ^|

Would offer "not_found", "failed", "parse_error" in the completion list.

Checklist

My suggestion meets these guidelines:

  • 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, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Experience EnhancementNoncontroversial enhancementsHas ReproThis issue has compiler-backed repros: https://aka.ms/ts-reprosSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions