`make` allocates and initializes `a`, setting it to nil effectively uninitializes the variable. See below, where I declare `c`, but don't initialize it. From the Golang spec, http://golang.org/ref/spec#Map_types, the value of an uninitialized map is nil.
In Go, nil is a value, not a type.
Assigning 'nil' to an interface only assigns the value, not the type.
An interface has both a value and a type at runtime, but is "nil" only if both the value and the type are nil.
It's really hard to think the term nil is a value.
IMO, this is a bug in language design. If it's truly a value, I think they should choose a different term rather then `nil` as like they choose `panic/recover` instead of `throw/catch` because they're semantically different.
And also, I really don't know how should I detect nil reliably for an interface type.
Comments
But: http://play.golang.org/p/J46-8OEWYS
`make` allocates and initializes `a`, setting it to nil effectively uninitializes the variable. See below, where I declare `c`, but don't initialize it. From the Golang spec, http://golang.org/ref/spec#Map_types, the value of an uninitialized map is nil.
http://play.golang.org/p/J46-8OEWYS
Don't tell me, I merely added one line of code to show that more information than the interface{} being nil is kept.
This is even more interesting.
In Go, nil is a value, not a type. Assigning 'nil' to an interface only assigns the value, not the type. An interface has both a value and a type at runtime, but is "nil" only if both the value and the type are nil.
It's really hard to think the term nil is a value.
IMO, this is a bug in language design. If it's truly a value, I think they should choose a different term rather then `nil` as like they choose `panic/recover` instead of `throw/catch` because they're semantically different.
And also, I really don't know how should I detect nil reliably for an interface type.
[deleted]
Oh I think I found what happens, see http://golang.org/doc/faq#nil_error