> if they want that information from the borrow checker how would they get it?
If you want to compare if two pointers point to the same place, you use https://doc.rust-lang.org/stable/std/ptr/fn.eq.html
Rust just defaults to value equality over reference equality. This is true for everything, not just ZSTs.
(I find the post's framing of "it's stored in the borrow checker" to be a bit odd, but I can't put my finger on exactly what it is. The borrow checker doesn't determine these sorts of semantics, it checks for liveliness and aliasing, so "do these pointers alias" isn't inherently not the borrow checker's job, it just strikes me as an odd way to put it. Maybe it's because you don't "ask the borrow checker for that information" really.)
As the article itself discusses, pointers to zero sized objects are not necessarily different (they write it is only the case in debug mode).
> I find the post's framing of "it's stored in the borrow checker" to be a bit odd
That's exactly what I wanted to say as well.
I feel like it would have been better to just skip the borrow checker mention and just go "in rust this can not be done reliably ..(section about pointers being the same)"
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.