proposal: spec: add Nullable constraint

[MrTravisB]

func foo[T any](param T) {
	if param == nil {
		// do a thing
	}
}

This is invalid

invalid operation: cannot compare param == nil (mismatched types T and untyped nil)

Would be nice to have a nullable constraint so that the following could be done

func foo[T Nullable](param T) {
	if param == nil {
		// do a thing
	}
}

[seankhliao]

where would this be useful?

[randall77]

Would this work for you?

func foo[T comparable](param T) {
        var x T
	if param == x {
		// do a thing
	}
}

[earthboundkid]

Nilable is a bad constraint because nil is overly broad. Forgive me for not searching for issue numbers, but there's already a long issue about splitting nil into nilinterface vs nilptr vs nilchan, nilslice, and nilmap. Right now there's no constraint that can guarantee that T is an interface. That would be more helpful.

More generally, the issue to add a built in zero should be adopted. You can compare functions to nil but not each other.

For now you can work around this by writing a func something[T any](t T, iszero func(T) bool). Most constraints can be replace with a callback that does whatever the constraint is meant to enforce.

[Jorropo]

Would this work for you?

func foo[T comparable](param T) {
        var x T
	if param == x {
		// do a thing
	}
}

I have a case where no, in my case T is an interface, it is not comparable then, but it is nil-able.
(if I try to use this I obviously get <symbol> does not implement comparable)

[earthboundkid]

There is also an issue to make interfaces comparable. #52624 We got issues for everything. :-)

Here is adding more specific nils: #22729

Here is adding a universal zero: #53666 Edit, that's the dup. Original is #35966.

Again, I think most constraints can be replaced with callbacks, but even without doing that a Nilable constraint is too broad and an Interface constraint would be more useful (although it really confuses the question of what a constraint is, since interfaces can't contain interfaces).

[atdiar]

Maybe the issue is that every type should be comparable to its zero value? (whether they satisfy comparable or not)
In which case it does not need an additional specific constraint but it requires a notation for the zero value?

[Jorropo]

@carlmjohnson

Again, I think most constraints can be replaced with callbacks

But but performance ? (replacing a single compare instruction by a virtual call seems silly)

an Interface constraint would be more useful

👍
Is there an issue for the virtual constraint yet ?

[Jorropo]

@atdiar

In which case it does not need an additional specific constraint but it requires a notation for the zero value?

I think you are asking for #53666.

[atdiar]

@atdiar

In which case it does not need an additional specific constraint but it requires a notation for the zero value?

I think you are asking for #53666.

Yes, kind of. The idea is there but the zero value of a string is not nil for example. So I wouldn't call it that way.

Since every type is comparable to its zero if I'm not mistaken, generic code would not need a constraint for if T == zero(T) {...}

[Jorropo]

if T == zero(T) {...}

I don't think this syntax is obvious enough, I think a:

func isZero[T any](v T) bool

builtin would be better

(It would not be a real function, the compiler would replace thoses calls with compares to 0 of the right size.)

PS: it would be different from reflect.ValueOf(v).IsZero() because it would target the passed type, not the underlying type.
In other words this:

emptyString := ""

var interfaceContainingTheEmtpyString any = emptyString

fmt.Println(isZero(interfaceContainingTheEmtpyString)) // false, because it isn't a nil interface
fmt.Println(reflect.ValueOf(interfaceContainingTheEmtpyString).IsZero()) // true, because reflect use the assertion rules and look at the underlying type, and "" is the zero value of the empty string.

[atdiar]

Well, we need a zero(T) anyway since we need to be able to return the zero value in generic functions that require it.

[Jorropo]

Fair. However we can already do this using @randall77 suggestion:

var zero T
return zero

You can also use named return values and not assign to them, ...

[earthboundkid]

func isZero[T any](v T) bool has to be written this way (notice the pointer and Elem()), so that it works with interface types:

func isZero[T any](v T) bool {
   return reflect.ValueOf(&v).Elem().IsZero()
}

I've used this code in some libraries. isZero("") is significantly slower than s == "", from ~1ns/op to ~20ns/op, plus it can escape to the heap. I would prefer if #35966 were accepted instead.