Support Intellisense for string/number literals in a widened union

[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.

[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]

👋 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

❌ Failed: -

• Argument of type '"not"' is not assignable to parameter of type 'ErrorStatus'.

Historical Information

Version	Reproduction Outputs
4.2.2, 4.3.2, 4.4.2, 4.5.2, 4.6.2	⚠️ Assertions:

[orta]

( I've updated the comment which should make the output above make more sens e on the next run )

[orta]

I was surprised to find a PR to the DOM lib types microsoft/TypeScript-DOM-lib-generator#1467 actually using a side-effect in union handling to get this feature!

// @errors: 1002
type T = "off" | "on" | "name" | (string & {});

declare function t(t: T){}

t("any string")
t("on")

(edit: removed the twoslash repro because it doesn't take completions into account )

[typescript-bot]

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

---

Comment by @orta

❌ Failed: -

• Unterminated string literal.
• ')' expected.

Historical Information

Version	Reproduction Outputs
4.5.2, 4.6.2, 4.7.2, 4.8.2, 4.9.3	❌ Failed: - Unterminated string literal. ')' expected.

[DanielRosenwasser]

Search tags: open ended string union literal auto complete

See also #26277