SE-0494: Add `isIdentical(to:)` Methods for Quick Comparisons to Concrete Types

[vanvoorden (Rick van Voorden)]

@8675309

I think this API needs a much clearer name, and something that distinguishes it further from ==. In English, isIdentical is more or less a synonym to isEqual.

There exists a long-standing prior art in Standard Library that "equal" representations are not always "identical-indistinguishable" representations:

@bbrk24

This isn't the only place that makes reference to equal values being distinguishable, e.g. on SetAlgebra's insert(_:) method:

Return Value

(true, newMember) if newMember was not contained in the set. If an element equal to newMember was already contained in the set, the method returns (false, oldMember) , where oldMember is the element that was equal to newMember. In some cases, oldMember may be distinguishable from newMember by identity comparison or some other means.

This has shipped for years in Standard Library. There does not seem to ever have been any big controversy about this… but if you have the opportunity to volunteer with more research please respond back if you find out any interesting details about the evolution of SetAlgebra that might help us here.

@8675309

To me, a non-compiler engineer, it’s still not clear what “identical” actually means. The underlying storage is the same so it must be the same? Or does it mean we can sometimes provide an O(1) shortcut, even if it’s not comparing underlying storage?

Before I get too far in the weeds with this answer… it might be helpful to slow down and also review some goals with the proposal:

• Primary: Our most important goal is to define a set of isIdentical(to:) methods on concrete types. This means that every type in this proposal should be ready to define its public semantics and guarantees so that library maintainers can then build impactful implementations.
• Secondary: A less important goal is to define an "abstract" set of "informal" guidelines that are not only an umbrella blanket over the concrete types in this proposal but might also cover future concrete types in Standard Library — and any library — that attempts to add isIdentical(to:).
• Tertiary: A "nice to have" goal is to then attempt and "backdeploy" that abstract set of guidelines to existing types like Span that already shipped isIdentical(to:) before this proposal.

So if we want to have a discussion about what "is identical" really means… it might be helpful then to slow down if we are attempting to go too far down the road of an "abstract" protocol definition that we expect all future concrete types to adopt. That is not — and should not be — a primary goal of this proposal.

But if we did want to discuss some more abstract concepts behind these ideas I collected some more thoughts here that might help:

What is a "copy"?

It might sound like an "easy" answer… but I am struggling to find where the definition of this might be documented. For example: This tells me that a type which is Copyable is a type that can be copied… but then what does that mean? There might be some more clues in SE-0390: All currently existing types in Swift are copyable, meaning it is possible to create multiple identical, interchangeable representations of any value of the type. But then what does that mean? Are "identical" and "i…

I briefly thought about putting this down as an "appendix" on the proposal… but I don't feel like I have strong enough opinions to attempt to codify this all down to some kind of "canon" treatise that would then serve as a prior art for future proposals. But in general my thoughts here so far are:

• Copies are representations that are "identical-indistinguishable".
  • Copies are representations that the compiler can be free to insert or remove on your behalf with zero expected changes on the surface meaning of your program.^[1]
• Representations that are "identical-indistinguishable" are "interchangeable-substitutable".
  • Representations that are "identical-indistinguishable" are not necessarily copies.
• Representations that are "interchangeable-substitutable" produce the same behavior in a program or algorithm that depends on the value properties of this representation. This does not include object identity or any other public state that is not considered as part of the public value.
  • Representations that are "interchangeable-substitutable" are not necessarily "identical-indistinguishable".

This possible missing piece here so far for me is to what extent we can attempt to define what it means to "be identical" as a "weaker" guarantee than what it means to be "a copy". But again… this all should not be a primary goal of this proposal. Our primary goal should be to define the semantics and guarantees of isIdentical(to:) on concrete types. We feel the existing proposed header doc comments are strong enough promises to make for an impactful API and I am not yet persuaded to change my opinion about that.

@8675309

Reading the Alternatives Considered, this actually seems like the most logical public API:

Exposing Identity

Our proposal introduces a new instance method on types that uses some underlying concept of “identity” to perform quick comparisons between two instances. A different approach would be to return the underlying identity to product engineers. If a product engineer wanted to test two instances for equality by identity they could perform that check themselves.

There’s a lot of interesting directions to go with that idea… but we don’t think this is right approach for now. Introducing some concept of an “escapable” identity to value types like Array would require a lot of design. It’s overthinking the problem and solving for something we don’t need right now.

I’d vote for making the current proposal use an underscored method in the short-term and work on the above alternative long-term.

We are not considering exposing identity at this time. A potential future direction that exposes identity should not block this existing proposal from shipping. Here are some more thoughts on that:

@lorentey

Returning the abstract "identity" of a container as a value in its own right exposes information about implementation details that do not need to be exposed, and are not worth exposing.

I am fully on board with the proposition that people sometimes do have a legitimate need for a way to quickly test if two containers are entirely identical without going through the a full equality test. (I regularly need that myself.) This is merely asking for a narrow performance hook -- an entirely reasonable request, with very few opportunities for abuse or unforeseen consequences. We can easily satisfy this need by simply adding a single member function.

[…]

There is no need to go overboard and invent the notion of an abstract identity, decoupled from the object it identifies.

[…]

Array is expressly designed not to expose an identity for itself -- it prefers to pretend it is a simple value type. By only adding a narrow isIdentical(to:) function, we'd be chipping away at this illusion, but we wouldn't completely shattering it.

Exposing a fully formed identity raises too many questions for comfort:

• Will people expect that identifier to change whenever the container is mutated? What if some container types did that, and people started assuming that it is a general requirement?
• Will people expect that the identifier only changes when the container is mutated in a way that makes it reallocate its storage? (Again, what if some containers did that, and people start assuming that is a general requirement?)
• Will people expect that identifiers never get reused, even if a container gets destroyed? (That has been a constant issue with ObjectIdentifier, despite the docs.)

To properly design a container identifier, we'd need to think about such questions, and some poor soul will likely have to write documentation on the recommended design patterns for such types. I believe this would be completely unnecessary work. We don't need to go overcomplicate this like that -- the actual problem doesn't need it.

---

1. What is a "copy"? - #2 by Joe_Groff ↩︎