unique symbol lost on assignment to const despite type assertion

[dragomirtitian]

🔎 Search Terms

unique symbol widening

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

Playground Link

💻 Code

const u = Symbol();
const a7 = u as typeof u // widened  to symbol

🙁 Actual behavior

a7 is symbol

🙂 Expected behavior

a7 has typeof u

Additional information about the issue

This issue is a huge problem for isolated declarations as it breaks the assumption that in an expression const o = a as T we can always use T as the type of o. This is also inconsistent with the way similar expressions work for string/number literal types (ex)

Similar issues:

• unique symbol type lost after property is extracted from an object #43657 - Widening on return type not on variable declaration
• Explicitly annotated unique symbols are widened in return positions #55361 - Similar, explicitly typed variable is widened
• Symbol type is incorrectly generalized when used as a property value of an object literal #36876 - Widening when assigning from object property (but no assertion)
• unique symbols from the global SymbolConstructor widen way too eagerly #53276

Mateusz Burzyński (@Andarist) perhaps #54778 also fixes this?

[jakebailey]

#54778 doesn't appear to fix this, no: Playground Link

[Andarist]

#54778 doesn't fix this because this value symbol isn't publicly accessible. The issue arises in the very same if statement that this PR touches though.

It probably would be possible to preserve this type by emitting smth like:

declare const u: unique symbol;
export declare const a1: typeof u

But the machine for this is not in place because those symbol types are widened at getWidenedTypeForVariableLikeDeclaration stage and not at the declaration emit - so the original information is lost before the declaration emitter has even a chance to deal with this.

Symbols are a little bit wonky in this regard so I assume that there are some intricacies to this that I'm not aware of etc. I found that preserving their types is often quite impossible without explicit type annotations. I could probably tweak my PR to handle this as well but I'm not exactly sure what should the rules for symbols be.

[jakebailey]

Yeah, this seems intentional:

// always widen a 'unique symbol' type if the type was created for a different declaration.
if (type.flags & TypeFlags.UniqueESSymbol && (isBindingElement(declaration) || !declaration.type) && type.symbol !== getSymbolOfDeclaration(declaration)) {
    type = esSymbolType;
}

Dropping this "fixes" this: f5b0327

[dragomirtitian]

Mateusz Burzyński (@Andarist)

#54778 doesn't fix this because this value symbol isn't publicly accessible. The issue arises in the very same if statement that this PR touches though.

The accessibility of the symbol is not really the issue. Even with an exported symbol you still get the same widening:

export const u = Symbol();
export const a7 = u as typeof u // widened  to symbol

Playground Link

[Andarist]

I was referring to my branch :P TS playground

[luisfonsivevo]

I ran into this today during some routine ts adoption. The codebase in question is using a "symbols as keys" pattern hundreds of times, so I'm experiencing this bug very frequently.

const key1: unique symbol = Symbol("hello");
const key2 = key1;
const key3 = key1 as typeof key1;
const key4: typeof key1 = key1;

const accessMe = { [key1]: "you have accessed me" };

accessMe[key1] = "key1"; //working
accessMe[key2] = "key2"; //Element implicitly has an 'any' type
accessMe[key3] = "key3"; //Element implicitly has an 'any' type
accessMe[key4] = "key3"; //working

[gershy-clutch]

Is there a downside to preventing the unique symbol -> symbol widening, other than performance (and potential backwards compatibility concerns)?