Indexed symbol types

[yuhr]

🔍 Search Terms

"non-unique symbol types", "symbol type with key", "indexed symbol types"

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

TypeScript should be able to express symbol types indexed with their key, reflecting the behavior of JavaScript's Symbol.for("some key"), by a new syntax like symbol<"some key">.

This feature won't break existing code if it doesn't come with a change to the types of Symbol.for, Symbol.keyFor, and Symbol.prototype.description, but I'd rather like to see it happen, possibly behind a new tsconfig option like "indexedSymbolTypeInference": true.

📃 Motivating Example

const symbolForSomeKeyDefinedInVersionA = Symbol.for("some key")
const symbolForSomeKeyDefinedInVersionB = Symbol.for("some key")
const shouldBeAssignable: {
	[symbolForSomeKeyDefinedInVersionA]: undefined
} = {
	// Statically fails here for now.
	[symbolForSomeKeyDefinedInVersionB]: undefined,
}

💻 Use Cases

1. What do you want to use this for?

Making multiple versions of the same library compatible.

Sometimes a library generates objects with a private property at a unique symbol key and use it as some kind of marker to statically or dynamically determine if an object is really generated or already processed with the library, while allowing users to define arbitrary properties on it as much as possible.

But what if a user has to end up depending on multiple versions of the library somehow? To address this, the library should accept objects from other versions of the same library, so the library might want to start using non-unique symbols for the purpose. This does work at runtime but not at compile time due to the absence of indexed symbol types.

Using a string key instead of a non-unique symbol key invades the string key space of such an object at runtime, and could conflict with an index signature at compile time.

2. What shortcomings exist with current approaches?

There's no current approaches for this.

3. What workarounds are you using in the meantime?

None.

[Richiban]

I too would very much appreciate this, since the status quo makes Symbols very difficult to use in Typescript. For example, it feels very wrong that this results in a compiler error:

const mySymbol = Symbol.for("my-symbol")

function foo(a: typeof mySymbol) {

}

foo(Symbol.for("my-symbol")) // Error: Argument of type 'symbol' is not assignable to parameter of type 'unique symbol'.

If, as OP says, Symbol.for(x) returned unique symbol<typeof x> (for string literals at least; unique symbol<string> is just Symbol), we could start using JS symbols the same way Erlang uses atoms or Ruby uses symbols.

[ExE-Boss]

Duplicate of #35909 (comment)

[ExE-Boss]

I personally prefer global symbol "name".

[yuhr]

Thanks pointing!