I think GP is calling for == to only compare boolean values ("equivalence"), = to be necessary for comparing any other values ("equality"), and := to be used for assignment. Though I don't see the purpose in that, given that two boolean values are equal if and only if they are equivalent.

Unless "equivalence" is supposed to be useful for comparing boolean expressions with unbound variables? But evaluating that would require a built-in SAT solver, to be remotely performant.

Also, just because two integers sum to 0 doesn't mean they're both equal to 0, so replacing (x == 0 && y == 0) with (x + y == 0) wouldn't be valid. Regardless, it wouldn't make for more performant code: compilers already translate (x == 0 && y == 0) into the assembly equivalent of ((x | y) == 0) automatically, without the programmer having to mess with their code.

> Also, just because two integers sum to 0 doesn't mean they're both equal to 0, so replacing (x == 0 && y == 0) with (x + y == 0) wouldn't be valid

Indeed, I forgot to specify unsigned.

That still wouldn't be valid, since either unsigned integers wrap around on addition (the default behavior of most languages), in which case nonzero values can still sum to 0; or unsigned integer overflow raises an error, in which case the transformation is dangerous unless the integers are both strictly bounded in magnitude.

Unless the integers were unsigned big-integers, in which case performing the long addition with carries would take Θ(n) time, as opposed to the simple Θ(1) operation of just checking both their bit-lengths.