Symbol Predicates S2
- Stage: Stage 2
- Status: Active
- ECMAScript edition: —
- Synchronized: Aug 28, 2026
- 中文译文 · Source repository
This proposal introduces two new predicates, Symbol.isRegistered and Symbol.isWellKnown, to differentiate symbols based on whether they are registered or well-known. It helps libraries determine if a symbol can be used as a WeakMap key or if it is truly unique.
The README below comes from the upstream repository and may contain outdated stage or status metadata. Use the proposal details above as the current source of truth.
Symbol Predicates Proposal
Status
Stage 2
Champions: Ashley Claymore, Jordan Harband
Authors: Robin Ricard, Ashley Claymore, Jordan Harband
Motivation
A proposal to introduce ways to differentiate symbols.
This proposal adds the following predicates:
Symbol.isRegistered(symbol)Symbol.isWellKnown(symbol)
Not all symbols are the same and knowing more about what they are can be useful, notably for libraries.
Knowing if a symbol is truly unique, is forgeable (registered) or is shared across realms (well-known), can be important depending on the use case.
For instance Symbols as WeakMap keys require symbols to not be registered.
Use Cases
You can detect in a library if a symbol can be used as a WeakMap key:
You can also find out if you are being given a truly unique symbol:
Description
Symbol.isRegistered(value)
Takes an unknown value as the only argument, returns a boolean: true if the symbol is registered, false otherwise.
Symbol.isWellKnown(value)
Takes an unknown value as the only argument, returns a boolean: true if the symbol is one of the well known symbols as defined by ECMA262 & ECMA402, false otherwise.
Implementations
Note that the two predicate packages belo are not polyfills; but they precisely match the current spec text, so they represent valid implementations of the proposal.
Symbol.isRegistered(symbol): https://github.com/inspect-js/is-registered-symbolSymbol.isWellKnown(symbol): https://github.com/inspect-js/is-well-known-symbol
Maintain the proposal repo
- Make your changes to
spec.emu(ecmarkup uses HTML syntax, but is not HTML, so I strongly suggest not naming it ".html") - Any commit that makes meaningful changes to the spec, should run
npm run buildand commit the resulting output. - Whenever you update
ecmarkup, runnpm run buildand commit any changes that come from that dependency.