Whoops, I looked at the IsZero code and totally missed this.

Noting here: @ianlancetaylor says in #61372 (comment):

The reflect.Value.IsZero method, for a non-comparable struct type, currently checks the value of blank struct fields. I am suggesting that v == zero should not check such fields, because we ignore them in ordinary == comparisons. And perhaps we should change reflect.Value.IsZero to match that.

In the example:

fmt.Println(reflect.ValueOf(negZero).IsZero()) // false, should be true if negZero == zero
fmt.Println(reflect.ValueOf(negStructZero).IsZero()) // true
fmt.Println(reflect.ValueOf(negArrayZero).IsZero()) // true

I think these should all report true. Is that what everyone else thinks too?

Change https://go.dev/cl/517777 mentions this issue: reflect: make Value.IsZero identical to v == zero

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

I might be misunderstanding how generic functions are compiled, but does this mean that the compiler has to track which type arguments are floats so that it can compile the == zero check differently?

Or... what is this supposed to print, once zero is recognized? https://go.dev/play/p/7fT1qQiBUGO?v=gotip

does this mean that the compiler has to track which type arguments are floats so that it can compile the == zero check differently?

The compiler already has to use floating-point equality semantics for any use of == if the type argument is a floating-point type. That doesn't change with the introduction of a builtin zero.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://go.dev/cl/524615 mentions this issue: reflect: update IsZero to handle negative and ignore blank fields