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

[vanvoorden (Rick van Voorden)]

@xwu

@vanvoorden

One missing piece we saw previously is that when T is not Equatable we do not formally define under what conditions isIdentical ever returns false.

At the risk of sounding like a broken record, we ought to have good, real-world motivating examples for the use of this API to determine our desired semantics. For instance, for values of some type T that are never Equatable, what can one usefully do that isIdentical would make faster or more expressive?

I don't really understand what this comment is asking for. This comment is implying that we should determine our desired semantics from "real-world motivating examples". But this comment is specifically directed at my attempt to begin to define semantics across any type that implements isIdentical. I can't give you real-world examples… it's already a discussion about an abstract type.

That being said… the clear prior art in this space is Span.isIdentical. Span is not Equatable. Here is all SE-0447 tells us about isIdentical:

Identifying whether a Span is a subrange of another:

When working with multiple Span instances, it is often desirable to know whether one is identical to or a subrange of another. We include functions to determine whether this is the case, as well as a function to obtain the valid offsets of the subrange within the larger span:

extension Span where Element: ~Copyable {
  /// Returns true if the other span represents exactly the same memory
  public func isIdentical(to span: borrowing Self) -> Bool
  
  /// Returns the indices within `self` where the memory represented by `span`
  /// is located, or `nil` if `span` is not located within `self`.
  ///
  /// Parameters:
  /// - span: a span that may be a subrange of `self`
  /// Returns: A range of offsets within `self`, or `nil`
  public func indices(of span: borrowing Self) -> Range<Index>?
}

Across 30 comments in a pitch thread, 36 comments in a second pitch thread, and 78 comments in a review thread, not one engineer asked for real-world examples to justify the inclusion of an isIdentical function and not one engineer asked for an additional discussion to clarify the semantics of the isIdentical function.

What I am not saying is that every attempt to ship a new type in standard library that implements isIdentical and is not Equatable must not present real-world motivating examples during design review. That is a decision that can take place between a proposal author and LSG. If LSG makes the decision that a new type should present real-world motivating examples during a proposal review then the proposal author can present those examples. I have zero problem with this.

What I am saying is that I am not persuaded that we must enforce here — in this proposal — that every type that implements isIdentical and is not Equatable must present real-world motivating examples. This clearly is not a requirement that must always be enforced — just look at Span.

@xwu

For that matter, what concrete types in the stdlib that are never Equatable are we thinking about here?

All the concrete types in this specific proposal are either always Equatable (like String) or conditionally Equatable (like Array).

While Span predates this proposal I do believe it would be desirable if the discussion of what "general" behaviors we want and expect isIdentical to adopt "in the abstract" could conceptually "backdeploy" to what already shipped on Span. But I am not 100 percent committed to this POV and I can drop this if it slows us down from shipping this.