1 of 13

Symbols as Weak Keys

for Stage 3

Leo Balter

2 of 13

Primary Goals of this proposal

  • Use non-object unique primitive values as keys for Weak referenced values.

​

Footer

3 of 13

What's new?

var unique = Symbol();

var wm = new WeakMap();

​

{

const obj = {};

wm.set(unique, obj);

}

​

wm.has(unique); // true

Footer

4 of 13

Support for other "Weak" APIs

This proposal also extends functionality to allow Symbols in WeakSets, WeakRefs and FinalizationRegistry, matching consistency with WeakMap keys.

​

​

Footer

5 of 13

WeakSet, WeakRef, and FinalizationRegistry

var unique = Symbol();

​

var ws = new WeakSet();

ws.add(unique);

​

var wr = new WeakRef(unique);

​

var registry = new FinalizationRegistry(heldValue => {

// ....

});

​

registry.register(unique, 'something');

​

​

Footer

6 of 13

Status

​

​

  • Spec draft with normative changes
  • Proposal repo.
  • Draft PR to ECMA-262 (WIP).
  • A fair amount of previous discussions.
  • Stage 2.
  • Reviews:
    • Bradford S. Smith, Jordan Harband, Daniel Ehrenberg
    • Editorship: Kevin Gibbons

Footer

7 of 13

Consensus for Stage 3?

​

​

Footer

8 of 13

Thank You

9 of 13

Proposed alternative

​

​

Restrict Symbols to be truly unique.

  • Disallow symbols registered in the GlobalSymbolRegistry List (symbol.for)
  • Disallow well-known symbols

Why?

  • All symbols would imply extra internal steps in engines to verify current liveness, this is not a desired change.
  • WM keys should be unguessable and unreachable by any code that does not also explicitly have access to the WM. Allowing a Symbol breaks that.

​

Footer

10 of 13

Proposed alternative

​

​

Restrict Symbols to be truly unique.

  • Disallow symbols registered in the GlobalSymbolRegistry List (symbol.for)
  • Disallow well-known symbols

Why not? (general arguments against this alternative)

  • Weak collections will have a check for non truly unique Symbols
  • Requires Developer to sanitize code

​

​

Footer

11 of 13

Use Cases

This proposal itself provides better ergonomics for distinct values being used just as keys of WeakMaps.

​

Rather than creating custom meaningless objects, symbol values can provide a better purpose while still being primitive values.

​

ECMA-262 already specifies symbols as primitive values to be used as unique non-string keys.

Ergonomics

Footer

12 of 13

Use Cases

Symbols, dereferenced through WeakMaps, is a reasonable option as a way forward to reference Objects from Records and Tuples.

​

The alternative is using the Box semantics but that seems to be unresolved yet.

​

Records & Tuples can't contain objects, functions, or methods and will throw a TypeError when someone attempts to do it.

Records and Tuples

Footer

13 of 13

Use Cases

Membrane systems are used on top of Realms for communication in virtualized environments.

​

Membranes rely on WeakMaps with many references of values used cross realms. Using symbols as keys to capture membrane references would be a good case to meet better ergonomics.

​

In the current API model for Realms, objects can't be accessed cross realms. This proposal would allow a membrane system to access distinct from different realms to be directly used as WeakMap keys.

Realms and Membranes

Footer