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

[vanvoorden (Rick van Voorden)]

@davedelong

This should be expressed as a protocol, so it can be used as a generic constraint

Our first pitch thread proposed a new Distinguishable protocol which was completely independent of Equatable. The big ergonomic problem for us was then managing the amount of generic overloads this would lead to for engineers using the API:

@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 add an overload that falls back to that, and a third overload if we also want to support types that conform to both. I don't think there is a reasonable way to merge the Equatable and Distinguishable variants into a single function; the only way I can see to do that is by doing runtime as? downcasts, and doing that would generally be costly enough not to be worth the effort of implementing the shortcut in the first place.

This led to the second pitch thread: which proposed adding a member requirement to Equatable. But we failed to come up with any compelling reason why this must ship right now as a protocol in standard library.

@John_McCall

Because the requirement is abstract and provided by arbitrary Equatable types, it struggles to define its expected semantics, which often only make sense in the context of a specific conforming type like Array or String. It also has to introduce optionality to the result type, which really feels like it ought to be reflected statically: if many types do not provide a meaningful implementation of this operation, perhaps it shouldn't be available on those types.

We would prefer to move forward with only the proposal that adds concrete isIdentical methods to the CoW types in the library. If experience with that proposal reveals that it is useful to have a generalization, we can reconsider this then. That is how generic proposals are best developed, by generalizing them from an existing pattern that's come to be well-understood. I've agreed to be review manager for these proposals, so I'll go read that proposal document and see if I have comments to make on the PR.

One clear missing piece for us to prioritize shipping a protocol in standard library would be if anyone from standard library could highlight for us code operating on a generic context that demonstrates clear and measurable performance improvements once this protocol is available in standard library. Another option would be if an anyone from a "high-profile" ABI stable library like SwiftUI could highlight for us a place where having this protocol available from standard library demonstrates clear and measurable performance improvements over some generic context.

If we don't have those perf wins waiting for us… then it's not clear for us why this must ship in standard library at this moment. Our preference is for library maintainers that want this protocol to ship their own protocol for their own generic contexts to constrain over. And if this incubates "in the wild" and the community seems to find some impactful use out of this pattern then I'm all for coming back to discuss either the Distinguishable protocol — or update to Equatable — at some future point in time.