Re:Understand Go pointers
by shanemhansen on Wednesday April 26, 2017 @03:14PM
(#14206052)
> In Go, pointers are actually (type, address) tuples, so a nil pointer to a custom struct is actually (pointer CustomStruct [1], nil)
I could be wrong but I think that's not right. The key difference is dynamic vs static dispatch. What you're describing (type, address) is how go represents interfaces. So go can resolve a.Read() on an io.Reader if the value is (os.File, nil). A go empty interface is not like a c void pointer for that reason. Type info is preserved and can be safely recovered.
But go also has non-virtual method calls unlike Java (afaik), it doesn't implicitly dynamic dispatch. This is a consequence of the fact that it doesn't have inheritance. If you write var foo os.File; foo.Close(); there's no runtime (type,address) tuple. That .Close() call is essentially compiled directly to something like CALL os.File.Close(nil). This can potentially be inlined even. If your method treats nil specially that's up to you.
I could be wrong but I think that's not right. The key difference is dynamic vs static dispatch. What you're describing (type, address) is how go represents interfaces. So go can resolve a.Read() on an io.Reader if the value is (os.File, nil). A go empty interface is not like a c void pointer for that reason. Type info is preserved and can be safely recovered.
But go also has non-virtual method calls unlike Java (afaik), it doesn't implicitly dynamic dispatch. This is a consequence of the fact that it doesn't have inheritance. If you write var foo os.File; foo.Close(); there's no runtime (type,address) tuple. That .Close() call is essentially compiled directly to something like CALL os.File.Close(nil). This can potentially be inlined even. If your method treats nil specially that's up to you.