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

[vanvoorden (Rick van Voorden)]

@pyrtsa

If isIdentical(to:) seems to cause confusion, why nor consider isCopy(of:)?

Probably then I would reference back to this earlier example:

@ksluder

The whole point of this tangent was to illustrate a plausible implementation of isIdentical(to:) for which it would not be accurate to say that the two SubSets have the same representation, because one could use positive indexing while the other uses negative indexing.

And this:

@vanvoorden

Suppose we then attempt to call isIdentical(to:) on self and other. Each String can be inline or buffer.

Let's start with the situation where self and other are both buffers. Here we compare the buffer reference for identity equality and return true if our pointers are equal. This is an O(1) operation. Simple.

Suppose self and other are both inline. If our library maintainer enforces that inline strings are never more than k bytes of data we can then compare these two values directly. Because the k value here is fixed we can still consider this to be an O(1) operation. Simple.

Suppose now one value is inline and one value is a buffer. What now? Because our inline strings are never more than k bytes of data we could choose to compare the inline value against the first k bytes referenced from our buffer reference pointer. This is still a constant O(1) operation and we can return true to indicate these values are identical. A library maintainer could also make the argument that these two values should not compare as identical… but I would think of it as totally legit to go ahead and perform this comparison since we do not break the semantic performance guarantees of the operation.

Take that previous example but instead assume we are implementing hasSameRepresentation(as:). Now it's implying something stronger than "is identical". If we attempt to compare one value that is inline and one value that is buffer it now looks like our library maintainer has far less flexibility. The name of the API is telling our library maintainer what the implementation should be. Even if our library maintainer wanted to compare the first k bytes of a buffer to an inline value the name of the API actively discourages this flexible thinking.

Whether we go with isCopy(of:) or hasSameRepresentation(as:) we seem to be communicating something stronger than what we really need. We do not need — or want — to require that library maintainers return true only if other is a copy of self. It's good enough to return true if other is only "identical" to self: with the library maintainer being responsible for choosing to document in what capacity an identical representation could differ from a copy.