Axel Rauschmayer wrote:
>> So there's no need for this
>
> There is one use case (admittedly a rather hypothetical one): 
> serializing the Symbol.* symbols to a text format (e.g. an encoding in 
> JSON).

Symbols that user-code puts into the registry do not serialize this way, 
so why should the well-known ones?

If you want to write a JSON helper-pair (toJSON or a replacer, with a 
correponding reviver, I think), then you can indeed serialize and 
deserialize symbols. But there's no ES6 backstage default-wiring from 
JSON to Symbol.for/keyFor.

/be

Axel Rauschmayer wrote:

> There is one use case (admittedly a rather hypothetical one): 
> serializing the Symbol.* symbols to a text format (e.g. an encoding in 
> JSON).

Symbols that user-code puts into the registry do not serialize this way, 
so why should the well-known ones?

If you want to write a JSON helper-pair (toJSON or a replacer, with a 
correponding reviver, I think), then you can indeed serialize and 
deserialize symbols. But there's no ES6 backstage default-wiring from 
JSON to Symbol.for/keyFor.