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

[vanvoorden (Rick van Voorden)]

@allevato

I noticed that StaticString wasn't included among among the supported types in this proposal. I think there's an argument that it would be reasonable to include it. (There's probably also an argument to skip it.) Let's assume that we added it. Given two StaticStrings, we could determine whether they're identical using this API, but the lookup would still be awkward because we'd have to reach for the underlying pointer directly (which StaticString does expose, but other APIs may not).

Please correct me if I'm wrong… but AFAIK product engineers are unblocked today to build their own isIdentical implementation on StaticString with public APIs:

extension StaticString {
  func isIdentical(to other: Self) -> Bool {
    guard
      self.hasPointerRepresentation == other.hasPointerRepresentation,
      self.isASCII == other.isASCII
    else {
      return false
    }
    if self.hasPointerRepresentation {
      return self.utf8Start == other.utf8Start && self.utf8CodeUnitCount == other.utf8CodeUnitCount
    } else {
      return self.unicodeScalar == other.unicodeScalar
    }
  }
}

This already looks like a constant-time operation. I don't see any room for a ton of impact from building a new isIdentical symbol directly in standard library on StaticString. I'm not blocking another engineer from proposing that… I'm just not personally making myself available for writing the implementation (and the tests… and the benchmarks…) at this time.

Looking from the other direction… shipping isIdentical on StaticString does not unblock any of the isIdentical implementations already being proposed. They are conceptually related… but orthogonal and complementary.

@allevato

While it's probably more of a future direction than something required by this proposal, have you given thought to an "identity hash" operation that would be the hashing analogue to this quasi-equality comparison, and what that might look like?

I'm not completely sure I understand what your idea is here… are you suggesting that we can implement a new method that returns a "hashValue" after trading accuracy for speed? This might be an interesting idea… but I don't see why that blocks anything being proposed here currently. We also don't really want to expose or escape any transformation of the underlying identity. We don't want to expose the identity to give product engineers creative ways to make use of the identity… we want to use the identity inside to then return something we believe is useful: if two instances are indistinguishable from each other.