[Pitch #2] Add `isIdentical` Methods for Quick Comparisons to Concrete Types

vanvoorden · August 19, 2025, 11:44pm

Discussion about Infix Operators and Symmetry

Just an observation here specifically WRT the discussion about enforcing semantics across all concrete types:

[Pitch #2] Add `isKnownIdentical` Method for Quick Comparisons to `Equatable`

[Pitch #2] Add `isKnownIdentical` Method for Quick Comparisons to `Equatable`

The main objection I have to lhs.isKnownIdentical(to: rhs) is that identity checking, like equality checking, should not treat the two sides differently. a.isKnownIdentical(to: b) should be the same as b.isKnownIdentical(to: a). And it is. But a?.isKnownIdentical(to: b) is not the same as b?.isKnownIdentical(to: a) and that is easy to miss.

On this note, it's also worth pointing out that the section on Argument Labels in the Swift API Design Guidelines calls out the situation you're talking about, saying

Omit all labels when arguments can’t be usefully distinguished, e.g. min(number1, number2), zip(sequence1, sequence2).

While that does seem to focus specifically on the labels, I think there's an unstated implication that an API that doesn't distinguish between two (or more) arguments shouldn't privilege one of them by making it the receiver—and the prior art of functions like min and zip reinforce that.

So the "unstated implication" here is that if we defined this operation through === we are limiting the flexibility that library maintainers might need.

Suppose for example a library maintainer had some code path where they needed to forward === through to Span.isIdentical:

struct S {
  static func ===(_ lhs: Self, _ rhs: Self) -> Bool {
    guard
      lhs.hasStorage,
      rhs.hasStorage
    else {
      return lhs.span.isIdentical(to: rhs.span)
    }
    return lhs.storage === rhs.storage
  }
}

So it's not completely idiomatic here for S to "promote" lhs to be the receiver of the isIdentical operation on span. Unless maybe if Span.isIdentical gave us the formal guarantee of symmetry… which I do not currently see guaranteed in the documentation.

The option then might be to enforce that === must also be an symmetrical operation such that a === b is the same as b === a. But I'm not yet persuaded that symmetry must be enforced at an abstract level across all these operations. I have no problem with library maintainers of a concrete type making that decision for themselves when appropriate to do so. I'm just not convinced we need to always enforce that everywhere.

…

But now that I go back and think through again… there must be some kind of convention here that infix operators do not take labels and still distinguish between arguments. How else could a < implementation not just flip the arguments and return the wrong answer?

It looks like the declaration of === does not formally confirm Reflexivity, Symmetry, or Transitivity:

github.com/swiftlang/swift

stdlib/public/core/Equatable.swift

swift-6.1.2-RELEASE


      
          /// Returns a Boolean value indicating whether two references point to the same
          /// object instance.
          ///
          /// This operator tests whether two instances have the same identity, not the
          /// same value. For value equality, see the equal-to operator (`==`) and the
          /// `Equatable` protocol.
          ///
          /// The following example defines an `IntegerRef` type, an integer type with
          /// reference semantics.
          ///
          ///     class IntegerRef: Equatable {
          ///         let value: Int
          ///         init(_ value: Int) {
          ///             self.value = value
          ///         }
          ///     }
          ///
          ///     func == (lhs: IntegerRef, rhs: IntegerRef) -> Bool {
          ///         return lhs.value == rhs.value
          ///     }

This file has been truncated. show original

So unless maybe that is hiding out somewhere else… we do not explicitly guarantee that x === y must imply y === x. Which is surprising…

I do think that even without this explicit semantic guarantee any product engineer that looks at === probably expects it to respect Symmetry. And if we defined a new set of === operators on these types I think it would be fair to assume those project engineers also expect Symmetry there.