Comment 1:

What would you have it do? It can't send anything.

Comment 2:

I don't know what it should do, but not panicking would be a good start.
I actually came across this while encoding a struct with a []interface{}
field that had a nil pointer in amongst stuff like non-empty strings. Isn't
that a reasonable data structure for gob to be able to encode/decode?

Comment 3:

I think a panic is the right thing to do. It could return an error but there's nothing
to do if the error occurs because nothing is sent, and that will violate the wire
protocol.
Consider this code:
enc.Encode(x)
enc.Encode(y)
You should always check errors, of course, and something else could go wrong, but it's
reasonable to consider that in a working, debugged program this transmission can always
be decoded by doing, on the remote side,
dec.Decode(&x)
dec.Decode(&y)
The thing is, if x and y are both of type *T, no message will be sent for that pointer,
and the value of y will be decoded into x.
In short, attempting to send a top-level nil is a pretty serious violation of the
streaming protocol. Of course, it's trivial to return an error and expect the user to
check for error, and I could be talked into that, but I want to be clear that you cannot
send a top-level nil ever. The gob package is not at fault here; the client is
misbehaving.

Comment 4:

I wrote via email but it hasn't shown up yet:
I don't believe it is. gob doesn't know what a pointer is: everything gets flattened.
Putting a nil pointer in an interface{} value creates a non-zero value (it's not the nil
interface) that gob cannot send (it can't express 'nil pointer').

Comment 5:

"I don't believe it is" is a response to comment #2. One of code.google.com's many
excellent features is that you cannot include quoted text.

Comment 6:

I don't believe it is. gob doesn't know what a pointer is: everything
gets flattened.
Putting a nil pointer in an interface{} value creates a non-zero value
(it's not the
nil interface) that gob cannot send (it can't express 'nil pointer').
Russ

Comment 7:

Correct. An interface value can be transmitted only if the concrete value itself is
transmittable. At least for now, that's equivalent to saying that interfaces holding
typed nil pointers cannot be sent.
I can try to make the panic more descriptive, but actually "fixing" this is a
significant design change.

Comment 8:

Can at least a non-top-level nil pointer result in an error instead of a
panic?

Comment 9:

This issue was closed by revision ea3c3bb.

Status changed to Fixed.