Should we expose a way to perform a "identity/reference equality" check?

[rickbutton]

• My issue is not bikeshedding. (we can bikeshed at
  a later proposal stage)
• My issue is not a request to add lots of stuff to
  the semantics. (we can add things in follow-on proposals)
• My issue is appropriate for a stage 0 proposal and not too
  in-the-weeds.

We've gotten at least one piece of feedback that it would be nice to be able to perform a physical equality check on records and tuples, specifically because it is more common in functional languages to have both a physical and structural equality comparison operator.

I wasn't sure exactly why this would be useful, so I asked around, and got some feedback from some OCaml people. In OCaml, there is both a physical equality and structural equality operator. The physical equality operator was identified as most useful if the domain of values being compared is hash cons-ed, (effectively interned via a hash table). If the allocations of the values are entirely controlled, then all structurally unique values will only ever exist once, which means that physical equality guarantees structural equality. This would be useful as a way to provide a consistently fast comparison, as it would likely just result in a pointer check.

While this feature seems useful in the above mentioned scenario, I don't think that this proposal would benefit from it's inclusion. There is precedent (citation needed) for implementors rejecting features that expose significant implementation details, and exposing physical equality of value types would fall into that category pretty plainly. If the ecosystem started relying on the way that a specific implementation represented values, it would cause significant problems when/if the implementation wanted to change.

I'm opening this issue to catalog the feedback we've received, and the feedback on the feedback I've solicited.

[ljharb]

When you say physical, do you mean identity?

[rickbutton]

@ljharb yeah, physical === identity in this context. I'm using physical here because the feedback came from the functional programming world, specifically OCaml, where it is referred to as physical equality

[ljharb]

If they’re primitives, they don’t have identity separate from their contents - every 3 is the same 3.

If they’re objects, then === must compare identity and not contents.

What are you suggesting be done differently as a result of this feedback?

[rickbutton]

Right. Every 3 === 3, every "foo" === "foo", but === doesn't guarantee that both values are "physically/referentially" the same, i.e. effectively stored in the same memory location.

I don't think we should change anything based on this feedback, I'm merely cataloging it here so that it can be tracked. I think that exposing whether two values are stored in the same memory location would expose far too much implementation detail to be acceptable, but want to recognize the validity of the use case in other languages.

[ljharb]

Sure, "memory" isn't really a concept that is exposed to JS users.

[littledan]

Thanks for filing this issue. I think it's good to track, even if we have good reasons for the current state of the proposal (without such an equality check). To clarify the discussion in this thread, maybe we could say "pointer equality" rather than "physical" or "==="--pointers are clearly not a concept exposed to JavaScript, but the question is whether we want to expose some such concept. It sounds like @rickbutton and @ljharb are in agreement that we don't, and @bakkot has expressed the same in other threads.

CC @leebyron who raised this issue offline.

[rickbutton]

@littledan , works for me, pointer equality makes more sense in the JS implementation world.

[ljharb]

The term "pointer" is also imo a very confusing term to use in a JS context, since there aren't really pointers nor memory - "reference equality" seems to be the term I've seen most often, if not "identity".

[littledan]

@ljharb Do you have a term that you would suggest for this concept?

[ljharb]

I suggested two.

[littledan]

Sorry, right, I see "identity" above. We can talk about whether these "have identity".

[ljharb]

Also "reference" - do they reference the same thing.

[rickbutton]

From discussions with other delegates and engine implementers, this doesn't seem feasible to add. JavaScript doesn't have the concept of pointers or physical equality or memory in the traditional sense, and the spec does not provide any guarantees around how value types should interact with those concepts. Because of this, I believe a physical/identity/memory/pointer equality check would not be useful enough to end users to justify it's existence.