Symbol definition improvement

Search Terms

symbol in:title, symbol improvement, symbol description definition

Suggestion

By using more and more symbol in my projects, and to make debugging easier in development mode, I fill the optional description to Symbol. Then, on production, I remove all description during the bundling process:

So I was thinking that it could be really useful to have the same approach for TypeScript - playground:

Just imagine we don't have xsymbol<"test"> but the "native" symbol<"test"> or symbol("test") to be closer to DevTools.

Then, by extending this approach, I don't know if it could be helpful to increase the typing inference.
Given this code:

const foo = {
    type: 'foo' as 'foo',
    foo: ''
};

const bar = {
    type: 'bar' as 'bar',
    bar: ''
};

type FooBarAction = typeof foo | typeof bar;

function getType<T>(input: {type: T}): T {
    return input.type;
}

function foobar(action: FooBarAction) {
    switch (action.type) {
        case getType(foo):
            action.foo;
            break;
        case getType(bar):
            action.bar;
            break;
    }
}

Here, according to the type property value, the action provide correctly foo property or bar property.

But, if I replace them by symbol:

const sFoo = {
    type: Symbol('sfoo'),
    sfoo: ''
};

const sBar = {
    type: Symbol('sbar'),
    sbar: ''
};

type SFooBarAction = typeof sFoo | typeof sBar;

function sfoobar(action: SFooBarAction) {
    switch (action.type) {
        case getType(sFoo):
            action.sfoo;
            break;
        case getType(sBar):
            action.sbar;
            break;
    }
}

Here TypeScript cannot resolve properly the correct definition of my action variable and keep saying that it get the SFooBarAction type, so only type property is available.

According to this PR #30196, I understand that working on symbol in the core system of TypeScript is not an easy thing, but probably it could be helpful if the optional description of Symbol as a definition descriptor to have the unique symbol in the definition. But definitely, as soon as we provide same description, we will face the same problem as today.

Full Playground

Use Cases

For the first part, everywhere when we use Symbol.

For the second part, as soon as unique value is required, like for Event Emitter, Action in Redux architecture, ...

Examples

See above on the Suggestion section

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.

リンクされた TypeScript Playground の例を再現することから始め、string-discriminant cases と Symbol cases を比較し、関連する PR #30196 を確認してください。この作業には、Symbol descriptions、unique values、control-flow narrowing について確定した設計と、それに対応するコンパイラーの動作、および要求された推論を示すテストが必要になります。