[Pitch #2] Add `isKnownIdentical` Method for Quick Comparisons to `Equatable`

[tera]

@vanvoorden

Hmm… I would maybe start with a comment from the previous pitch:

@lorentey

First, the bitwise equality of two objects does not necessarily imply that they are identical. An object's identity sometimes includes the location of its bits in addition to their value. For example, this is the case for noncopyable synchronization constructs like struct Atomic and struct Mutex -- two distinct atomic integers are never identical, even if at some point they both happen to have the same integer value, i.e., their storage consists of the same bits. Some Swift types are not bitwise comparable.

I must admit I do not fully understand this bit. Is it only applicable to non copyable types? How would I be able to even attempt to compare the two (presumably identical) variables if the type is non copyable to begin with? (without always getting a known result of false, I mean). Could you give an example?

(This can also go in the other way. Two semantically identical Swift values can sometimes differ in their bit patterns due to padding bytes whose values are unspecified and can vary. In general, raw bitwise equality can be used neither to deny nor confirm that two Swift objects are identical.)

This bit is fully understandable. Yes, there could be some false negatives due to padding, which is not guaranteed to be zeroed. Not a show stopper on my list as it doesn't break the semantic contract (false positive would), but YMMV of course.

@vanvoorden

Why is all that conditional logic and custom code needed? I have no idea… but I know I don't want to break it.

Great detective work, thank you.

@vanvoorden

If a type does not have any ability to answer isKnownIdentical without a comparison equal in effort to normal value equality, then that type should return nil.

So Int and other similar types would return nil in their isKnownIdentical implementation?