== One reason why Go can have methods on nil pointers

I was recently reading [[an article on why Go can call methods on
_nil_ pointers
http://blog.riff.org/2014_09_20_calling_methods_on_null_objects_in_go_and_php]]
([[via
https://www.reddit.com/r/golang/comments/2gxwg8/why_can_go_call_methods_on_nil_instances/]])
and wound up feeling that it was incomplete. It's hard to talk about
'the' singular reason that Go can do this, because a lot of design
decisions went into the mix, but I think that one underappreciated
reason this happens is ~~because Go doesn't have inheritance~~.

In a typical language with inheritance, you can both override methods
on child classes and pass a pointer to a child class instance to a
function that expects a pointer to the parent class instance (and
the function can then call methods on that pointer). This combination
implies that the actual machine code in the function cannot simply
make a static call to the appropriate parent class method function;
instead it must somehow go through some sort of dynamic dispatch
process so that it calls the child's method function instead of the
parent's when passed what is actually a pointer to a child instance.

In non-_nil_ pointers to objects, you have a natural place to put
such a [[vtable http://en.wikipedia.org/wiki/Virtual_method_table]]
(or rather a pointer to it) because the object has actual storage
associated with it. But a _nil_ pointer has no storage associated
with it and so you can't naturally do this. That means given a _nil_
pointer, how do you find the correct vtable? After all it might be
a _nil_ pointer of the child class that should call child class
methods.

Because Go has no inheritance this problem does not come up. If
your function takes a pointer to a concrete type and you call
_t.Method()_, the compiler statically knows which exact function
you're calling; it doesn't need to do any sort of dynamic lookup.
Thus it can easily make this call even when given a _nil_.
In effect the compiler gets to rewrite a call to _t.Method()_
to something like _``ttype_Method(t)''_.

But wait, you may say. What about interfaces? These have exactly
the dynamic dispatch problem I was just talking about. The answer
is that [[Go actually represents interface values that are pointers
as two pointers http://research.swtch.com/interfaces]]; one which
is the actual value and another points to (among other things) a
vtable for the interface (which is populated based on the concrete
type). Because Go statically knows that it is dealing with an
interface instead of a concrete type, the compiler builds code that
calls indirectly through this vtable.

([[As I found out GoNilNotNil]], this can lead to a situation where
what you think is a _nil_ pointer is not actually a _nil_ pointer
as Go sees it because it has been wrapped up as an interface value.)

Of course you could do this two-pointer trick with concrete types
too if you wanted to, but it would have the unfortunate effect of
adding an extra word to the size of all pointers. Most languages
are not interested in paying that cost just to enable _nil_ pointers
to have methods.

(Go doesn't have inheritance for other reasons; it's probably just a
happy coincidence that it enables _nil_ pointers to have methods.)

PS: it follows that if you want to add inheritance to Go for some
reason, you need to figure out how to solve this _nil_ pointer with
methods problem (likely in a way that doesn't double the size of
all pointers). Call this an illustration of how language features
can be surprisingly intertwined with each other.