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

[vanvoorden (Rick van Voorden)]

@xwu

I don't understand the distinction here you are making between "same representation" and "representations as identical": these seem like synonymous terms and I'm not sure why one implies different semantics than the other.

We already have the axiom that a copy is a representation that is identical. But I do not believe we need the axiom that a representation that is identical is a copy. A "copy" seems to be a much stronger guarantee than we need for library maintainers to ship isIdentical(to:) as an impactful API:

@Joe_Groff

For a Copyable type, copies are literally interchangeable with each other without changing the surface meaning of the program (though obviously can affect the performance characteristics). If you have

foo(a)

then

let b = copy a
foo(b)

will behave exactly the same. The compiler by this principle is free to insert or remove copies to improve performance or maintain language semantics.

If there does exist legit documentation in Standard Library or evolution where we formally define that identical representations are also copies then please show me where to find that. I searched around everywhere I could think of and the only clues I could find implied the other direction: that copies are identical.

Anyway… the point of this was that I would see nothing wrong with a library maintainer choosing to implement isIdentical(to:) in a way that does not always compare as "same bitwise representation". As long as that library maintainer can adopt and satisfy the semantic guarantees then they should be free to have that extra flexibility here.