proposal: reflect: reflect.ValueOf(nil).IsNil() panics; let's make it return true

[robpike]

The IsNil method of reflect.Value applies only to typed nils, so this program panics:

package main

import	"reflect"

func main() {
	x := reflect.ValueOf(nil)
	x.IsNil()
}

panic: reflect: call of reflect.Value.IsNil on zero Value

On the face of it, this is nuts: it says that nil is not nil. (What is this, a NaN? Just joking.) In fact, even asking if nil is nil causes the program to crash!

Every time I dig into uses of reflect, which would be rare except that I "own" several core packages that depend on reflection, I bounce off this. It just sits wrong with me that reflect.ValueOf(nil) gives the zero reflect.Value, but that is "invalid" not nil.

I propose, without thinking through the consequences in nearly enough detail, that either "invalid" becomes different from "value created from literal nil", or that we just change "invalid" to "nil" and allow it to satisfy IsNil.

I'm not sure this can be changed without causing a major ruckus, but I thought I'd at least ask. It might be easy and could clean up a fair bit of code in some places.

[mvdan]

change "invalid" to "nil" and allow it to satisfy IsNil.

I think this would be more likely to cause breakage, as I've seen the uses of the zero and invalid reflect.Value to signal "there is no value at all here - not even untyped nil". Here are some examples: https://cs.github.com/?scopeName=All+repos&scope=&q=%2Fvar+%5Cw%2B+reflect.Value%2F+language%3Ago

"invalid" becomes different from "value created from literal nil"

I think that's reasonable. If someone does want the invalid value, they can always do var invalid reflect.Value, and that's what I've seen in existing code so far. Unfortunately, it does seem like many pieces of code use reflect.ValueOf(nil): https://cs.github.com/?scopeName=All+repos&scope=&q=reflect.ValueOf%28nil%29+language%3Ago

[mvdan]

Here's a slightly better search for changing the zero value: Go files which do both var name reflect.Value and name.IsValid: https://cs.github.com/?scopeName=All+repos&scope=&q=%2Fvar+%5Cw%2B+reflect.Value%2F+%22.IsValid%22+language%3Ago

[mvdan]

Thinking outloud: can this be one of those instances where we change the behavior of a Go API based on the go 1.X version that the module containing the source code declares? For example, with go 1.17, reflect.ValueOf(nil).IsValid() == false as today, but with a future go 1.19, reflect.ValueOf(nil).IsValid() == true. Presumably that gets us the best of both worlds: make the API behave in an obvious way for new code, but avoid breaking existing code.

That kind of backwards compatibility might get a bit complex when reflect.Values cross module boundaries, but it would still be better than changing the API behavior for all existing code at once.

[rsc]

FWIW I am skeptical that changing this would be helpful enough to mitigate the breakage it will cause. The behavior is clearly documented:

% go doc reflect.IsNil
package reflect // import "reflect"

func (v Value) IsNil() bool
    IsNil reports whether its argument v is nil. The argument must be a chan,
    func, interface, map, pointer, or slice value; if it is not, IsNil panics.
    Note that IsNil is not always equivalent to a regular comparison with nil in
    Go. For example, if v was created by calling ValueOf with an uninitialized
    interface variable i, i==nil will be true but v.IsNil will panic as v will
    be the zero Value.

% 

[rsc]

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

[robpike]

I understand that it is documented; my point is that what is documented is far from intuitive. It was perhaps a mistake to make the zero value represent invalid and nil both. But I also understand it may be hard to change.

I wonder, though, what would actually break if reflect.ValueOf(nil).IsNil() did not panic.

[zigo101]

ValueOf returns a representation of the value boxed in the argument interface,
instead of the argument interface itself.
A nil interface boxes nothing. Maybe nothing should not be nil?

package main

import "reflect"

func main() {
	var v any
	y := reflect.ValueOf(&v).Elem()
	println(y.IsNil()) // true
}

[rogpeppe]

I wonder, though, what would actually break if reflect.ValueOf(nil).IsNil() did not panic.

That was my thought too.

I think it would probably be fine if:

• reflect.ValueOf(nil) returns the zero value of Value (as it does now)
• for the zero value of Value, IsNil returns true
• for the zero value of Value, Type returns nil.

In general a nil Type represents "no type" in the same way that the zero Value represents "no value", and nil is the nearest we've got in Go to a generic way to represent "nothing", so IsNil returning true seems reasonable to me.

I wonder if there's any code at all that would break if this behaviour were to change.

[rsc]

The big problem here is that reflect is about typed values yet in many use cases people want some representation for untyped nil. And reflect.ValueOf(nil) returns the zero reflect.Value, which people use as that representation.

So suppose we make the following changes to support that (assume v is the zero reflect.Value):

1. v.Type() == nil // untyped
2. v.IsNil() == true // untyped nil
3. v.IsZero() == true // any nil is a zero value, so probably the untyped nil is too

It's a little inconsistent but it will fix some code and probably won't break much, since all these panic today and code is written to avoid those panics.

Does anyone object to this?

[rogpeppe]

SGTM.

Note that Kind already works on the zero value, so there's definitely precedent for methods that don't panic other than IsValid.

[randall77]

I'm worried about the fact that if people start using reflect.Value{} for an untyped nil, then they are going to want to start using it more places, e.g. as an argument to reflect.Call. I think this would just push the confusion point elsewhere instead of solving it.

[robpike]

Maybe untyped nil could be a new Kind?