Comment by AnyTimeTraveler
1 hour ago
This can be done reliably, though. You can just do
if a == b { ...
Just that the check will be replaced at compiletime with a constant, since the borrow-checker tracks all objects lifetimes and can use that information to optimize the check away.
The objects themselves don't make it into the compiled binary, since they have no size, but all the required information about them will make it in. So you can treat them like ordinary objects and do all the usual operations on it, without wasting any memory during runtime.
In general our types won't be comparable, suppose we've got three zero size types Truth, Beauty and Strange and we make six variables a and b have type Truth, c and d are Beauty, e and f are Strange:
Out of the box a == b will not compile, for the same reason that in most languages you can't divide the string "This" by the string "That" you cannot use this operator here because it's nonsense unless somebody defines what it means.
We can define an implementation for this operator on Truth, but, it has nothing more to go on than what we already knew - remember these are zero size types so they do not have properties we could investigate, we can say they're always equal, in which case a == a is now true too, or indeed that they're never equal, in which case a == a is now false - they don't have identity, we can't tell them apart.
We're allowed to write implementations for comparisons to other types, so we could say you can compare a Truth to a Beauty, and a Beauty to a Strange, but you can't compare a Strange to a Truth for example, so then a == c would compile and so would c == f but a == f would not compile.
Yes, if the types are known none of this results in any actual operations at runtime because it'll get optimised out.