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

[vanvoorden (Rick van Voorden)]

@xwu

Yes, those directions would address that point of feedback, so I think you're interpreting what I meant to communicate correctly.

(However, as I said over in the other thread—the two threads going to the same design problem—I suspect key use cases are directly expressible by composing facilities we already have or will soon inevitably have...)

Thank you for helping me understand some points a little more clearly. I believe some previous comments address some more details that could be relevant to that:

@vanvoorden

If what you are suggesting is that checking for identity equality can exist independently of the Equatable protocol this was part of the original pitch and is currently an "Alternative Considered". One reason we kept this inside Equatable is to prevent against needing extra generic specialization overloads. Where a product engineer needs:

• One generic specialization for a type that is Equatable and is Spannable.
• One generic specialization for a type that is Equatable and is not Spannable.
• One generic specialization for a type that is not Equatable and is Spannable.

Since we expect product engineers want isKnownIdentical in-place of (or accompanying) the result of a == value operator we think keeping that in Equatable is the better trade off for now.

We currently consider an independent protocol outside Equatable to be an "alternative considered". The previous pitch took this direction… but the previous pitch review and discussion compared the pros and cons of an independent protocol and I changed my mind after hearing those points. We feel that keeping this on Equatable is the right trade off for now for this pitch.

@FlorianPircher

If I understand Span correctly, this only works for contiguous memory, not necessarily a Dictionary or some tree structure which cannot provide a span view.

My understanding is similar: we have access to Span for types like Array… but we will not AFAIK ever have access to an easy Span transformation for types like Dictionary. Coupling our "identity equality" to Span limits our flexibility to make use of this API.

@lorentey

I think having a distinct nil value as default does help by adding a little more sense to having this member on flat Equatable types like Bool or Int. The name isKnownIdentical does not quite match the behavior in this case, but it's pretty close. (isIdenticalIfAvailable would be quite bad, I think.)

The Standard Library includes ample precedent for adding optional protocol requirements in this nil-returning way. The result is usually not the most user friendly API, but it fits an established pattern, and it helps that (unlike withContiguousStorageIfAvailable and friends) this isn't a higher-order function:

func f3<S>(sequence: S) async throws
where S: AsyncSequence, S.Element: Equatable
{
  var oldElement: S.Element?
  for try await element in sequence {
    // Is this readable enough? Is it easy to figure out how to write it?
    if oldElement.isKnownIdentical(to: element) ?? false { continue }
    oldElement = element
    doLinearOperation(with: element)
  }
}

The previous pitch did not include a nil returning "default" value. This was added after the previous pitch review. We feel like nil communicates important information and context that is meaningfully different than what a false default value would represent.