[Pitch] `Distinguishable` protocol for Quick Comparisons

[vanvoorden (Rick van Voorden)]

@lorentey

I'm not fully ready to sign up swift-collections to ship a protocol like Distinguishable though -- I need more convincing that (1) it would fit within the mandate of that package, and (2) that it would actually carry its weight.

Ahh… ok… so it sounds like the suggestion then is:

• ship isIdentical on concrete types in standard library and foundation
• do not ship a standalone Distinguishable protocol
• potentially add a new function to Equatable to expose the identity equality

This makes sense. I can agree with these ideas.

@lorentey

(Note: This line of objection would quickly melt away if some high-profile ABI stable codebase like SwiftUI had a good reason to want fast generic identity tests -- but in that case, I think extending Equatable is the far better option -- see below.)

Correct. One of the places I could see this leading to measurable impact is an Observable type (that is Equatable and offers identity equality) that then recomputes a SwiftUI component body. The current plan is to ship a linear-time equality check inside Observable that filters new values before notifying observers.^[1] But this could potentially then make use of identity equality before notifying SwiftUI (which we assume might perform its own linear-time operation when values have changed).

@lorentey

The approach being pitched is this:

public protocol Distinguishable {
   func isIdentical(to other: Self) -> Bool 
}

func f3<S>(sequence: S) async throws 
where S: AsyncSequence, S.Element: Distinguishable 
{
  var oldElement: S.Element?
  for try await element in sequence {
    if oldElement.isIdentical(to: element) { continue } // Quick shortcut
    oldElement = element
    doLinearOperation(with: element)
  }
}

Note that Distinguishable is part of the algorithm's requirements; we cannot call this function on anything that doesn't conform to this niche protocol. To support calling it on classic Equatable elements, we'd need to decide an overload that falls back to that, and a third overload if we also want something that works on anything at all.

Correct. It gets bulky and clunky. My original thoughts were that increased flexibility from a Distinguishable independent of Equatable meant Distinguishable could be adopted by types like Span and RawSpan that do expose identity equality but do not expose value equality. But the argument you are making is those potential wins from the extra flexibility are not worth it when we consider the extra gymnastics and ceremony that would go into using Distinguishable from generic contexts that might also need to be generic over Equatable. Makes sense. I can agree with this.

@lorentey

I think it's a good idea for a member requirement solve just one problem -- the idea of quickly testing "definitely not equal" is a separate, far more controversial/ambiguous task, and it should not be forced to get tackled by the same member.

Yeah… I'm agreeing with this.

All good ideas. Thanks!

---

1. Understanding when SwiftUI re-renders an @Observable - #9 by jflan ↩︎