Map/Set’s SameValueZero key/value mapping

[bathos]

%Map% and %Set% use SameValueZero semantics for key comparison, but they additionally normalize -0 to 0:

Map.prototype.set(key, value)

4. If key is -0𝔽, set key to +0𝔽.

Set.prototype.add(value)

4. If value is -0𝔽, set value to +0𝔽.

So for example, [ ...new Set([ -0 ]) ][0] is 0, not -0. More importantly this means new Set([ -0, 0 ]) and new Set([ 0, -0 ]) behave equivalently — you can’t observe which zero happened to be added first.

The proposal’s updated SameValueZero will have SameValueZero(#[ -0 ], #[ 0 ]) === true (which makes sense), but I would expect corresponding updates in %Map.prototype.set% and %Set.prototype.add% that canonicalize* the key to include, at depth, only positive zeros. Presumably this would be realized with a new shared abstract op (e.g. ToCanonicalSVZValue) that could also encapsulate the existing -0 → 0 behavior.

* This is spiritually related to #291, but observable non-canonical NaNs showing up in weird places is a meta-issue that isn’t specific to this proposal. The Map/Set negative zero canonicalization on the other hand is an existing concrete/262-specified behavior.

[acutmore]

Hi @bathos

This is discussed (at length) in #65

[bathos]

Thanks @acutmore, sorry for the dupe. At length indeed! I remember reading that a while ago now, but missed the conclusion that it was intentional to break from the existing Map/Set canonicalization behavior.

Though I personally believe that behavior should never have existed in the first place, it does and can’t go away now, so I think the decision to depart from it here is unfortunate — it (unintuitively) adds more quirky complexity to Map/Set’s keying semantics, it doesn’t reduce it — but I appreciate that this has already been discussed in depth.