Typescript: Support Intellisense for string/number literals in a widened array

[orta]

Search Terms

autocomplete union wide

Suggestion

In both https://github.com/microsoft/TypeScript/issues/28743 and https://github.com/microsoft/TypeScript/issues/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

```ts repro
type ErrorStatus = 'not_found' | 'failed' | 'parse_error' | string;

declare function fail(status: ErrorStatus): any

fail("not")
// ^|
```

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

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

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

[AlCalzone]

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?

[fatcerberus]

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.

[jack-williams]

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

[AlCalzone]

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

[jcalz]

crosslinking to #29729

[typescript-bot]

:wave: 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 this issue running against the nightly TypeScript. If something changes, I will post a new comment.

---

Issue body code block by @orta

:warning: Assertions:

Historical Information

Issue body code block by @orta

Version	Reproduction Outputs
3.5.3, 3.6.4, 3.7.5, 3.8.3, 3.9.5, Nightly	:warning: Assertions: