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?

From https://play.golang.org/p/JOmxaVJoYtT,

	// var zero t
	// fmt.Println(a == 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?

One side would need to be known to be zero statically. Having a universal zero like in the linked issue would be the easiest way to achieve that.

Let's look at time.Time.
There is a IsZero function that will show you if the time is empty or not. With your suggestion I think that there should be an interface for structs and only if the struct is implementing that interface it can be checked against zero. For example if you have:

t := time.Time{}
fmt.Println(t == zero) 

It should be transferred to something like

var t time.Time
fmt.Println(t.IsZero())

This is not the same as t == nil, although t == nil doesn't make sense.

As mentioned in #35966, another solution would be a zero(T) bool builtin that worked for all T, which would be an option should no universal zero value be added.

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 f == nil is f == nil, since variables aren't statically nil and you can't make a constant nil other than n-i-l.

I think generics will require Go to either add an isZero() generic built-in or a "universal zero" identifier.

I'm running into a scenario right now where this would be extremely useful. What is the current intention and/or best practice for this problem if zero builtin has not been implemented?

You can fake it with reflect. See #35966 for discussion of solutions.

@carlmjohnson the reflect option is very slow when it comes to structs :/

Yes, that's why I am pushing for #35966 to happen.

I posted this in the cmp.Or thread but I should probably note it here as well. You can write an is-zero predicate now using generics and unsafe by taking advantage of the property that Go zero values imply all bytes are zero:

func Zero[T any](v T) bool {
	bp := (*byte)(unsafe.Pointer(&v))
	sz := unsafe.Sizeof(v)
	for _, v := range unsafe.Slice(bp, sz) {
		if v != 0 {
			return false
		}
	}
	return true
}

You can write an is-zero predicate now using generics and unsafe by taking advantage of the property that Go zero values imply all bytes are zero

Note that there some subtleties here around padding and fields named _. See #31450 (and read to the end).

Floats are weird, man.

f := math.Copysign(0, -1)
fmt.Println(ZeroAny(f), ZeroGeneric(f)) // false true

@josharian it looks like the decision was those are going to be kept zero for now? If I'm reading that correctly there's a hypothetical flaw in the naive check but nothing that can manifest today. Did I get that correct?

@carlmjohnson that is a fair point. It looks like reflect.IsZero handles that correctly but that float/complex are the only cases where this is wrong. That can't really be worked around today without doing something like this: https://github.com/zephyrtronium/number/blob/main/reflect.go#L32 Disappointing!

For comparable types, the compiler generates == functions. I had assumed that a single size-parameterized function would suffice to handle the is-zero case. At a minimum it looks like it would need to reuse == for comparables and generate is-zero functions for composite non-comparables containing float/complex. For the other non-comparables, the single function would suffice as long as padding/_ remains zero.

Fixed by acceptance of #61372