Define identity/equality operators by noamr · Pull Request #710 · whatwg/infra

noamr · 2026-05-08T17:55:50Z

Identical to (or is) is for primitives or by-reference comparisons
Equal is for shallow comparison of structs/lists/maps or custom data types, and is used by internal map/lists algorithms such as list/contains. It checks for cyclical references internally, using a private-type visited list.
Primitive data types specify their own "considered identical" overload.
Data types must specify "considered equal" in order to participate in list-contains or be map keys.

Closes #664

annevk

Do we really need three types? I don't understand why we can't define equals for lists. I also think that giving "equivalent" a normative meaning will be quite awkward as we often use it in notes and such to mean something else.

I also somewhat strongly prefer "is" over "identical". As it becomes more common having to scan over the long form will be annoying.

noamr · 2026-05-10T14:42:56Z

Do we really need three types? I don't understand why we can't define equals for lists. I also think that giving "equivalent" a normative meaning will be quite awkward as we often use it in notes and such to mean something else.

I was going by the discourse on the issue... I am not sure if deep-equals/equivalent is necessary or if it currently would be used by anyone. I am ok with dropping it for the time being.

Sure we can define equals for lists/maps etc, I was going by the discourse.

I also somewhat strongly prefer "is" over "identical". As it becomes more common having to scan over the long form will be annoying.

"Identical to" was already defined for strings and in some sentences it fits more naturally, as in "a and b are identical". Both forms are exported so perhaps it's ok to leave the choice to embedders?

annevk · 2026-05-11T06:44:48Z

Okay, thinking about this some more I think we want to borrow more of the original issue's ideas:

For identity comparison we can reuse the terminology is/identical to from strings.
Separate defining equality for something from the equals operator. So that you can say struct's equality is unordered deep equals, for instance.
Use deep equals and unordered deep equals instead of equivalent.
We should assert if we are comparing something with equals/deep equals and one of the underlying items has no equality.

I'm not sure how we should deal with cyclic references or whether lists/maps/structs should have a default equality that's not null. Perhaps we should start out with them not having a default and asserting until we get a bit more comfortable with it.

noamr · 2026-05-11T07:10:02Z

Okay, thinking about this some more I think we want to borrow more of the original issue's ideas:

For identity comparison we can reuse the terminology is/identical to from strings.

Separate defining equality for something from the equals operator. So that you can say struct's equality is unordered deep equals, for instance.

Use deep equals and unordered deep equals instead of equivalent.

We should assert if we are comparing something with equals/deep equals and one of the underlying items has no equality.

This seems unnecessary. It should fall back to shallow-equals/identity. E.g a map of map of structs where one of the struct items is a platform object - it's ok if those are compared by reference and everything else is deep-equals.

I'm not sure how we should deal with cyclic references or whether lists/maps/structs should have a default equality that's not null. Perhaps we should start out with them not having a default and asserting until we get a bit more comfortable with it.

annevk · 2026-05-11T07:33:58Z

For platform objects it seems okay to default (or enforce?) all of them to identity for their equality, but that should probably be in Web IDL.

noamr · 2026-05-11T07:53:43Z

For platform objects it seems okay to default (or enforce?) all of them to identity for their equality, but that should probably be in Web IDL.

Not sure I like this model. Maybe it is better to defer deep equality for now? Not sure if it has existing users?

annevk · 2026-05-11T07:55:47Z

I think Sanitizer essentially wants something like that? Not having equals for lists or maps at all probably won't work.

noamr · 2026-05-11T08:04:10Z

I think Sanitizer essentially wants something like that? Not having equals for lists or maps at all probably won't work.

Sanitizer just needs to define equality for the SanitizerConfig dictionaries such as SanitizerElement, and then all the map/list algorithms (mainly contains) should refer to that. It doesn't need to deeply compare entire lists.

annevk · 2026-05-11T08:16:52Z

I guess we don't have to define (unordered) deep equals for v1, but I think the point around equals and equality still stands. And so we'd still have to define somewhere what equality means for platform objects since I don't think we want it to default to is.

noamr · 2026-05-11T08:31:27Z

I guess we don't have to define (unordered) deep equals for v1, but I think the point around equals and equality still stands. And so we'd still have to define somewhere what equality means for platform objects since I don't think we want it to default to is.

In what scenario wouldn't we want to default to 'is'? Looks to me like unless there is a special equality operator like in URLs or structs it's probably the natural fallback?
Eg for js object references it's probably the most useful default.

noamr · 2026-05-11T09:47:00Z

I guess we don't have to define (unordered) deep equals for v1, but I think the point around equals and equality still stands. And so we'd still have to define somewhere what equality means for platform objects since I don't think we want it to default to is.

In what scenario wouldn't we want to default to 'is'? Looks to me like unless there is a special equality operator like in URLs or structs it's probably the natural fallback? Eg for js object references it's probably the most useful default.

nevermind, I've looked at this again and was convinced. See new revision.

annevk

I still miss a clear distinction between how you define equality for a concept and then how you compare it. Currently we do things like <dfn for=url>equals</dfn> but maybe it should actually be something like

A URL's equality, given a URL a and a URL b, is:

or maybe the <dfn> pattern is okay, but I don't see you employing that here for list and set (although you do for unordered).

Also for sets the unordered definition is the same as the ordered one, which seems wrong.

noamr · 2026-05-12T14:55:47Z

I still miss a clear distinction between how you define equality for a concept and then how you compare it. Currently we do things like <dfn for=url>equals</dfn> but maybe it should actually be something like

A URL's equality, given a URL a and a URL b, is:

Yes, we need to add that to the URL spec. Thinking to do there what we do here for strings, where there is still a <dfn for> for compat but it is also defined in terms of the "global" equality.

or maybe the <dfn> pattern is okay, but I don't see you employing that here for list and set (although you do for unordered).

I think you missed this line, which accounts for both list and set:

A list A is equal to a list B if A has the same size as B and A[i] is equal to B[i] for all indices i of A.

Also for sets the unordered definition is the same as the ordered one, which seems wrong.

Removed the extra one.

noamr · 2026-06-09T06:46:53Z

I think this is ready for another review?

JakobJingleheimer · 2026-06-21T12:40:36Z

Heads up: there is a similar/related proposal going in TC39 (comparisons).

- `Identical` (or `is`) is for primitives or by-reference comparisons - `Equal` is for shallow comparison of structs or custom data types - `Equivalent` is for deep comparison of maps/list/etc or custom data types Closes #664

Co-authored-by: Addison Phillips <addison@lab126.com>

identity/equality now have an exported algorithm as well as a type-specific "overload". When using the equality algorithms, a private "visited" list ("equality context") is forwarded, to avoid cyclical references.

Replace the identity check, equality check, and equality context machinery with three concepts: * "is" (or "identical to"): values of primitive data types are identical when they have the same contents; other values only when they are the same instance. * "equality": every data type has one, which is identity unless defined otherwise. * "equals": a is b, or a and b are of the same data type and its equality returns true for them. Lists, maps, and tuples define their equality by comparing their contents in order using equals. Other structs only equal themselves unless their definition specifies otherwise, e.g., using the new itemwise equality. This keeps the identity semantics specifications implicitly rely on for structs in lists and sets today. Drop the cyclic reference detection. It asserted on acyclic input (e.g., when comparing « « » » with a list containing it) and was not passed through contains or other equalities. Instead, an example cautions against comparing values that contain themselves. Furthermore: * Make map contains and get use equals, to match the requirement that no two keys are equal. Phrase the ordered set requirement the same way. * Rename set's "equal" to "unordered equal", keeping "equal" and the set-equal ID for compatibility, and add an example contrasting it with equals. * Drop the null and boolean identity statements and a stale string TODO, and clarify the number and byte sequence ones. * Rename the section to "Identity and equality", as its old ID would clash with the equality definition. * Add notes on using structs as map keys or set items and on changing a tuple into a struct. * Fix formatting and add Noam Rosenthal to the Acknowledgments.

annevk

I significantly reworked this as explained in the commit I added. I'm now happy with it. If this looks good to you as well Noam I can do some more work on ensuring we have PRs for the specifications that need changes as a result.

I'm not 100% sure about giving structs and tuples different equality by default, but it does make sense I think.

noamr · 2026-10-04T12:56:39Z

I significantly reworked this as explained in the commit I added. I'm now happy with it. If this looks good to you as well Noam I can do some more work on ensuring we have PRs for the specifications that need changes as a result.

I'm not 100% sure about giving structs and tuples different equality by default, but it does make sense I think.

Yea looks great! Thanks

annevk · 2026-10-05T08:39:21Z

Follow-up PRs created:

Follows whatwg/infra#710

Follows whatwg/infra#710.

annevk reviewed May 10, 2026

View reviewed changes

noamr changed the title ~~Define 3 types of equality (identical, equal, equivalent)~~ Define identity/equality operators May 11, 2026

annevk reviewed May 12, 2026

View reviewed changes

aphillips reviewed May 13, 2026

View reviewed changes

Comment thread infra.bs Outdated

mikewest mentioned this pull request Jun 12, 2026

Add initial patch for CSP:EE style iFrame Inheritance WICG/connection-allowlists#29

Merged

domenic mentioned this pull request Sep 3, 2026

Add URL path equality and prefix comparison whatwg/url#929

Merged

noamr and others added 11 commits October 3, 2026 14:45

Define 3 types of equality (identical, equal, equivalent)

cb01e57

- `Identical` (or `is`) is for primitives or by-reference comparisons - `Equal` is for shallow comparison of structs or custom data types - `Equivalent` is for deep comparison of maps/list/etc or custom data types Closes #664

grammar

5b18dfe

grammar

be7bd3c

Remove equivalent for now

48e9fcc

whitespace

42477d5

whitespace

435eb11

Fix missing newlline

12f72af

Remove extra set equality

be56838

Update infra.bs

74808e6

Co-authored-by: Addison Phillips <addison@lab126.com>

Assert when cyclical references found

5955651

identity/equality now have an exported algorithm as well as a type-specific "overload". When using the equality algorithms, a private "visited" list ("equality context") is forwarded, to avoid cyclical references.

a/an

755e594

noamr and others added 10 commits October 3, 2026 14:45

Make equality context more private

733eb53

Make equality context private

3e9fa07

Remove end tags

8af55d8

Fix some nits

285308f

Fix some AI-found nits

685fd0d

Fix DAG vs cycle detection in equal algorithm

0ea2bf4

nit

04f782c

Style nits

dab8cae

nit

9e7c905

annevk force-pushed the noamr/equality branch from b3e4576 to 411c455 Compare October 4, 2026 06:04

annevk approved these changes Oct 4, 2026

View reviewed changes

move equality up

d085f13

annevk merged commit c67ae1f into main Oct 5, 2026
2 checks passed

annevk deleted the noamr/equality branch October 5, 2026 08:34

annevk added a commit to whatwg/html that referenced this pull request Oct 5, 2026

Editorial: adopt Infra's equality

81b92f4

Follows whatwg/infra#710

annevk added a commit to whatwg/webidl that referenced this pull request Oct 6, 2026

Order dictionary entries by their members

8c65329

Follows whatwg/infra#710

annevk added a commit to whatwg/fetch that referenced this pull request Oct 6, 2026

Compare connection and CORS-preflight cache keys using equals

e9460d1

Follows whatwg/infra#710

annevk added a commit to whatwg/storage that referenced this pull request Oct 6, 2026

Define storage key equality

23f38d8

Follows whatwg/infra#710

annevk added a commit to whatwg/url that referenced this pull request Oct 6, 2026

Editorial: use Infra's equality for hosts, URLs, and URL paths

dcd3d6b

Follows whatwg/infra#710

annevk mentioned this pull request Oct 7, 2026

Editorial: use Infra's identity and equality whatwg/fs#189

Merged

annevk added a commit to whatwg/fs that referenced this pull request Oct 8, 2026

Editorial: use Infra's identity and equality

7df1158

Follows whatwg/infra#710.

Conversation

noamr commented May 8, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

noamr commented May 10, 2026

Uh oh!

annevk commented May 11, 2026

Uh oh!

noamr commented May 11, 2026

Uh oh!

annevk commented May 11, 2026

Uh oh!

noamr commented May 11, 2026

Uh oh!

annevk commented May 11, 2026

Uh oh!

noamr commented May 11, 2026

Uh oh!

annevk commented May 11, 2026

Uh oh!

noamr commented May 11, 2026

Uh oh!

noamr commented May 11, 2026

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

noamr commented May 12, 2026

Uh oh!

Uh oh!

noamr commented Jun 9, 2026

Uh oh!

JakobJingleheimer commented Jun 21, 2026

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

noamr commented Oct 4, 2026

Uh oh!

Uh oh!

annevk commented Oct 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

noamr commented May 8, 2026 •

edited by pr-preview Bot

Loading