4 ms·
The easiest way to remember this for your own use is to remember that, in Go, the == equality operator is a bitwise comparison. It will be true if and only if t
by chimeracoder 4y ago
The easiest way to remember this for your own use is to remember that, in Go, the == equality operator is a bitwise comparison. It will be true if and only if two entities are bitwise equal.
In Go, every value is stored as a tuple: (concrete type, value). So (int32, 5) is not the same as (int64, 5), even though the numeric value is the same.
In general, the compiler will prevent comparisons that are always going to be false, such as comparing an int32 to an int64: https://go.dev/play/p/q0skdfUnWsD https://go.dev/play/p/q0skdfUnWsD
The only time when you'll be able to compare two entities with identical values but different concrete types (and have your code compile) is when they're being compared through variables stored in an interface: https://go.dev/play/p/t0QDFh70Ut4 https://go.dev/play/p/t0QDFh70Ut4.
This can be surprising when you first encounter it, but once you understand how it works, it's easier to remember.
- skitter 4y ago> the == equality operator is a bitwise comparison With floats being the exception
- masklinn 4y agoAnd strings being the second exception. And complex as they're basically a pair of floats. And transitively any array or struct containing one of the exceptions. So really, == is mostly not a bitwise comparison, when you think about it.
- Dylan16807 4y agoWhat do strings do with == that isn't bitwise over the contents?
- masklinn 4y agoCompare the contents of the actual buffer. If == on string was a bitwise comparison, it would be an identity check. But two different strings with the same content compare equal, meaning go dereferences the buffer pointer.
- Dylan16807 4y agoSo it is comparing the contents exactly, the same as with an array or struct? In that case strings aren't an exception, looking at contents is just how structs work.
- masklinn 4y agoOh hey, flying goalposts, cool.
- Dylan16807 4y agoThe hell are you talking about? I used the same phrasing both times.
- DonHopkins 4y agoYou're the one who brought up comparing the contents instead of just the types and pointers. The first pair of goalposts was the fixed size comparison of the (type, pointer) bits of the string object reference, the second pair of goalposts was the variable length and arbitrarily long contents including the bits that the two different string pointers refer to. The bits of a structure containing a string don't also include the contents of the string itself.
- Dylan16807 4y ago"any array or struct containing one of the exceptions" is already talking about comparing the contents instead of the types and pointers. I didn't bring up the idea, I just said strings did the same, and with everything doing the same thing it's not an exception to bitwise comparisons, it's a general rule for how to handle nesting. Floats are still an exception, but not the rest of that list.
- deleted 4y ago[deleted]
- chc 4y agoThat is not really what's going on here. If you replaced the interface in the OP's example with the actual type being returned, the nil comparison would work as expected. It isn't that the interface is allowing a comparison that would otherwise cause a build error — the interface is creating an error that wouldn't exist otherwise.