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

[vanvoorden (Rick van Voorden)]

@scanon

@DanL

Q: Why can't we use == instead?

A: The compared objects could have slight differences even if == returns true,
and that could influence the result when performing operations on those objects.

This is true for some of the types in question, but it's not the real motivation. The actual reason is that if is[Trivially]Identical(to:) returns false, then == would have to check element-by-element, which is (roughly) just as expensive as the thing that you're trying to avoid calculating, so you'd often end up doing twice as much work if you used ==.

Correct. Here is another POV along those same lines:

@ben-cohen

You want a "maybe different" comparison, where "definitely equal" is a fast path, and "maybe different" will fire sometimes even when nothing differs.

The motivation being, an observer might be about to do some linear operation anyway when values have changed, and that linear operation is fairly similar in effort to an equality check in cases of false change notifications, so they might as well do it even when nothing has changed rather than pay the price of first checking for definitive inequality, then performing that work.