[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.

[vanvoorden (Rick van Voorden)]

@benrimmington

The "Introduction", "Motivation", "Prior Art", and "Proposed Solution" sections of the two proposals are essentially the same (very high on the déjà vu scale).

You're not wrong… it's a valid point and if these two pitches did turn into formal proposal design reviews I see no reason they must run concurrently with each other.

[toph42 (Topher Hickman)]

@vanvoorden

That was the answer: my POV was splitting apart "one large" pitch was better because two small pitches could be considered and shipped independently. Mixed feedback on Pitch B would not need to block shipping or landing Pitch A if the feedback on Pitch A was universally positive.

We've had pitches complete with "Partially Accepted" as an outcome. Were these two pitches presented together and the one half was well-received and the other not, that could happen without having introduced the confusion of two seemingly identical pitches (yes, I do understand the distinction, but I didn't before you explained it in the comments). I guess that's moot, though, as it's too late to avoid confusion now.

Edit: I guess the acceptance is actually for formal Proposals, not pitches, so I suppose that a single unified Proposal could still be made with both "halves" of the Proposal being independently evaluable.