In the example of gob usage http://golang.org/src/encoding/gob/example_interface_test.go they provide the following thesis: Pass pointer to interface so Encode sees (and hence sends) a value of interface type. If we passed p directly it would see the concrete type instead. See the blog post, "The Laws of Reflection" for background.
I've read The Laws of reflection twice, and a related Russ Cox article too. But I can't find a distinction between pointer-to-interface and interface there.
So why is it that through the pointer it sees a value of interface type, and with no pointer it sees (surprisingly to me) the concrete type?
It seems to me that the relevant part is this:
Continuing, we can do this:
var empty interface{} empty = w
and our empty interface value empty will again contain that same pair, (tty, *os.File). That's handy: an empty interface can hold any value and contains all the information we could ever need about that value.
(emphasis added)
When you assign an interface value to a value of type interface{}
, the "pointer to data" part of the new value doesn't point to the old value, but rather to the data old value was pointing to. We can prove that with a bit of unsafe
code:
type iface struct {
Type, Data unsafe.Pointer
}
var r io.Reader = &bytes.Buffer{}
var i interface{} = r
rr := *(*iface)(unsafe.Pointer(&r))
ii := *(*iface)(unsafe.Pointer(&i))
fmt.Printf("%v
", ii.Data == rr.Data) // Prints true.
On the other hand, if we use a pointer, it will point to the interface value itself. So now reflect
can actually see, what interface exactly are we talking about. E.g.:
var i2 interface{} = &r
ii2 := *(*iface)(unsafe.Pointer(&i2))
fmt.Printf("%v
", ii2.Data == unsafe.Pointer(&r)) // Prints true.
Playground: http://play.golang.org/p/0ZEMdIFhIj