Support Intellisense for string/number literals in a widened union

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.

_{keep it broken so people stop writing types like that}

There are situations when implementing 3rd party APIS where you know the options that there are right now, but future versions will absolutely add new options.
If you use a closed union type, you get auto completion but errors on every new option that is added. If you use string, you lose auto completion.
How to solve this dilemma?

I say this as someone who extolls the virtues of self-documenting code constantly...

IMO, this is conflating purely documentary concerns with typing concerns. In reality, the type is just string and we shouldn't pretend otherwise. I understand the value of having an automatic list of suggestions, but that feels more like the domain of documentation-level scaffolding such as JSDoc comments, rather than the type system proper.

type ErrorStatus = (('not_found' | 'failed' | 'parse_error') & tag "suggestions") | string;

Whoa, hold on. Will this actually be a use case of tag types? 😳

crosslinking to #29729

Orta Therox (@orta)

👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of the repro in the issue body running against the nightly TypeScript.

Issue body code block by Orta Therox (@orta)

‼️ Exception: Error - error TS5107: Option 'moduleResolution=node10' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error. Visit https://aka.ms/ts6 for migration information.

Error: error TS5107: Option 'moduleResolution=node10' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error.
  Visit https://aka.ms/ts6 for migration information.

    at Object.createVirtualTypeScriptEnvironment (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:8128:11)
    at twoslasher (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:7618:17)
    at /home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:439:44
    at runTwoslashRequests (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:406:56)
    at run (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:20096:75)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Historical Information