Thanks for the explanation,
The update I suggest is to add the following sentence to the end of the
reflect.Value.IsNil documentation:
Likewise, if v was created by calling ValueOf on an initialised interface{}
> value with a nil value pointer j, v.IsNil will return true, whereas j ==
> nil will return false.
Based on the following observation:
var m map[string]interface{}
var i interface{} = m
fmt.Printf("reflect.ValueOf(i).IsNil() == %t\n", reflect.ValueOf(i).IsNil())
fmt.Printf("i == nil == %t\n", i == nil)
// output:
// reflect.ValueOf(i).IsNil() == true
// i == nil == false
On Tuesday, 9 August 2016 14:43:41 UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Aug 9, 2016 at 6:23 AM, Sam Salisbury <[email protected]
> <javascript:>> wrote:
> >
> > All this gets me thinking, is there any use case where this fact is
> useful?
> > (I.e. a nil-valued interface not being equal to nil via the ==
> operator.)
>
> This has been discussed several times on the mailing list. An
> interface value == nil if it is the zero value of the interface type.
> It does not == nil if it holds the zero value of some other type, even
> if the zero value of that other type is nil. Many people would be
> surprised if
> var v interface{} = 0
> fmt.Printf("%t\n", v == nil)
> printed true. It should be equally surprising if
> var v interface{} = (*byte)(nil)
> fmt.Printf("%t\n", v == nil)
> printed true.
>
> The confusion results because Go, perhaps unfortunately, uses the name
> nil to designate both the zero value of an interface and the zero
> value of a pointer (and a slice or map or channel too, for that
> matter). If the names were different, this would be less confusing.
>
> > Also, should the reflect.Value.IsNil documentation be updated? It
> doesn't
> > mention this case where it differs*, only the one about it panicking on
> a
> > zero reflect.Value.
> >
> > * IsNil returns true for an interface{} with a nil value pointer, even
> > though '== nil' return false.
>
> What update do you suggest? You say there is a "case where it
> differs", but by my reading there is not. It may help to read
> https://blog.golang.org/laws-of-reflection .
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
