Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: spec: always permit comparisons against zero value of type #26842
Go, effectively, has three-kinds of comparability:
When writing code with known types, this is not an issue. You know if there's an
When generating code (or, possibly in the future, writing generic code) over arbitrary types, this asymmetry is a bit more bothersome. You can't just classify types as comparable or incomparable, you need to handle the 0-comparable case as well even though it is so similar: https://play.golang.org/p/JOmxaVJoYtT
I propose collapsing incomparable and 0-comparable. Allow incomparable structs and arrays to be compared to their zero value. There would always be an
I believe this would be a 100% backwards-compatible change and perhaps even simplify the spec a bit (or at least not require too many changes).
The concerns would be go/types and reflect, but they both seem to lump what I call 0-comparability in with incomparability, but there, admittedly, could be subtler implications.
This is tangentially related to defining a universal zero value #19642 (comment) in that similar arguments are involved and the two would compliment each other.
Does the zero value need to be static? Or it can be dynamic, as long as at run time, at the point of ==, the value is zero?
it seems to suggest that the zero value does not have to be static (it is a variable). What if the value is not zero, then? Panic?
Let's look at
It should be transferred to something like
This is not the same as
A related issue is that you can't define a const which is a nil func/slice because you can't define const func/slices:
const zero func() = nil // does not compile
So, as of now, the only way to write
I think generics will require Go to either add an isZero() generic built-in or a "universal zero" identifier.