Backstory/rationale for disallowing -0 in Map keys and Sets?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Backstory/rationale for disallowing -0 in Map keys and Sets?

T.J. Crowder-2
Negative zero (-0) is the only value you can't use as a Map key or a Set value. Map's [`set`][1] and Set's [`add`][2] both explicitly replace it with +0. MDN makes a point of saying that "early drafts" of the ES2015 spec treated +0 and -0 as distinct, but that "changed" in ES2015. Looking at some early drafts, at some stage Map and Set used SameValue (so you could have both +0 and -0 as Map keys or in a Set), then went through a period where you could specify a "comparator" for them (so a given instance would use SameValue or SameValueZero). Then that was removed; the final spec uses SameValueZero and has `set` and `add` replace -0 with +0.

Using SameValueZero and converting -0 to +0 when storing does have the effect of ensuring consistency: You don't end up with two sets (for instance) with different values (-0 and +0) that Set's comparison logic (SameValueZero) considers the same. (But then, so would using SameValue and converting from -0 to +0 earlier in the `set` and `add` algorithsm.) Using SameValue and allowing -0 would also ensure consistency, but with the ambiguity that -0 and +0 are often hard to distinguish (Number's `toString` returns `"0"` for both, for instance; operations involving them largely don't care about the pseudo-sign of 0). Is that the rationale? Basically, avoid a footgun while ensuring consistency?

Thanks,

-- T.J. Crowder


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Backstory/rationale for disallowing -0 in Map keys and Sets?

Allen Wirfs-Brock


On Oct 10, 2018, at 3:42 AM, T.J. Crowder <[hidden email]> wrote:

the ambiguity that -0 and +0 are often hard to distinguish (Number's `toString` returns `"0"` for both, for instance; operations involving them largely don't care about the pseudo-sign of 0). Is that the rationale? Basically, avoid a footgun while ensuring consistency?

Yes, exactly.

Also, at that time the proposed comparator parameter was already restricted to selecting between SameValue and SameValue0 because of concerns/open issues about an unrestricted comparator parameter.  After it was demonstrated that a subclass that distinguished ±0 was fairly trivial to write the comparator parameter was eliminated.

The assumption was that someday an extension proposal to add a generalized comparator parameter would be brought forward and considered.

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Backstory/rationale for disallowing -0 in Map keys and Sets?

T.J. Crowder-2
On Wed, Oct 10, 2018 at 7:03 PM Allen Wirfs-Brock
<[hidden email]> wrote:
> Yes, exactly.

Thanks!

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Backstory/rationale for disallowing -0 in Map keys and Sets?

Jordan Harband
The unfortunate result, however, is that a subclass that is *more* restrictive than the base class is not possible to write robustly - namely, if someone does `Set.prototype.add.call`, they'll bypass any of the criteria you've set up in the subclass.

I would have vastly preferred that the base class for both Map and Set used SameValue, and I'd have found a "SameValueZero" subclass to be much more trivial to write robustly than a "SameValue" subclass is now. That ship, unfortunately, has long since sailed.

On Wed, Oct 10, 2018 at 11:09 AM T.J. Crowder <[hidden email]> wrote:
On Wed, Oct 10, 2018 at 7:03 PM Allen Wirfs-Brock
<[hidden email]> wrote:
> Yes, exactly.

Thanks!

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss