Stage 2
Champions: Ashley Claymore, Jordan Harband
Authors: Robin Ricard, Ashley Claymore, Jordan Harband
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.
You can detect in a library if a symbol can be used as a WeakMap key:
function isWeakMapKey(key) {
switch (typeof key): {
case "object":
return key !== null;
case "function":
return true;
case "symbol":
return !Symbol.isRegistered(sym);
}
return false;
}
isWeakMapKey({}); // true
isWeakMapKey(Symbol()); // true
isWeakMapKey("foo"); // false
isWeakMapKey(Symbol.for("foo")); // false
isWeakMapKey(Symbol.asyncIterator); // true
You can also find out if you are being given a truly unique symbol:
const isUniqueSymbol = sym => typeof sym === "symbol" && !(Symbol.isRegistered(sym) || Symbol.isWellKnown(sym));
isUniqueSymbol(Symbol()); // true
isUniqueSymbol(Symbol.for("foo")); // false
isUniqueSymbol(Symbol.asyncIterator); // false
isUniqueSymbol({}); // false
Takes an unknown value as the only argument, returns a boolean: true
if the symbol is registered, false
otherwise.
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.
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
- 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 build
and commit the resulting output. - Whenever you update
ecmarkup
, runnpm run build
and commit any changes that come from that dependency.