This isn't a bug; U gets the GobDecode and GobEncode methods from the embedded T, so the encoder and the decoder use these implementations - which don't know anything about U's fields, and so can't encode or decode them - instead of the normal recursive walk. This is also true of similar interfaces for JSON, XML and the like.

As explained, it is working as intended. That's how embedded fields behave.

@robpike

FTR: I consider the "explanation" mostly irrelevant to the problem. It is clear how embedded fields work, but that just make us know why calling out.Gob{De,En}code works. But the program does not do that call. The call is performed in the stdlib's gob package and I'll try to explain why I think it's not correct to do so.

First of all, it's true that this is working as documented, because

A type that implements GobEncoder and GobDecoder has complete control over the representation of its data and may therefore contain things such as private fields, channels, and functions, which are not usually transmissible in gob streams.

However, I don't think the implementation is correct when seeing that U implements GobEncoder - but only through method promotion of T's method. The problem is that T's GobEncoder implementation has no way to know its receiver is embedded in another struct and access U's fields. This defeats the "complete control" quoted above. T has complete control of encoding U, when embedded in U, but in the same time no access to U's instance.

This can lead to some scenarios, which I consider problematic. One of them is the code in this issue, some random other:

• Something can work for a long time well in production. A day comes when someone adds an ambedded field to a struct implementing GobEncoder. Information is lost the next time gob encoding is used to store the information. It can easily be noticed only too late.

• Adding another embedded field of type say W, also implementing GobEncoder to the code in this issue makes the roundtrip work again, masking the problem. A day comes when someone removes one of the embedded fields and again, all except the one embedded field of U are not encoded anymore.

• Spooky action at distance. The embedded field does not implement GobEncode, but it is itself a struct and it's a type imported from another package. A day comes when any level down the promotion chain someone implements GobEncode on one of the nested, embedded fields and from that point all information from all the higher level embedders cease to be encoded.

These are all risky situations, not only from the data loss point of view, but it can be also a security risk, when certain fields stay unexpectedly at zero values when decoded from a gob encoding vaues with knowingly non zero value fields.

I think the proper handling should consider only types implementing GobEncode by themselves, not by promotion, because, let me repeat myself, in the case of using GobEncode promoted methods the type, in this case U, has actually zero, not 'full' control over how its data are encoded and decoded because it's actually done by the instance of the embedded type which methods got promoted and actually called.

PS: I haven't checked, but I assume reflection can distinguish between promoted methods and methods implemented directly by a type. If that assumption is false then there's of course probably no way to change/fix this.

I don't want to prolongue talking on a closed issue, but if this stays considered not a bug, I may submit a proposal to change gob's behavior, if someone thinks it should be done.

Everything you describe is working as expected and documented. Yes, you should be careful about embedding types that implement a GobEncode method. No, we should not add a special case to encoding/gob when handling embedded types. And, as you raise as a possibility, I don't even see a way to do this.

@ianlancetaylor

Yes, you should be careful about embedding types that implement a GobEncode method.

I see, thank you. WDYT about filling a documentation issue suggesting adding a reformulation of the above, something like

Do not use a single embedded field implementing GobEncoder in combination with other exported fields which do not implement GobEncoder. Any non-zero values of those will be lost on Encode. Even when an embedded field does not implement GobEncoder, you're at risk that when the type implements GobEncoder any time later, which may not be even under your control, the data-loss situation will/may arise unexpectedly without warning."

? It's not too hard to fall into this trap. The intent is to possibly save others the time I spent debugging when I run into this situation.

And, as you raise as a possibility, I don't even see a way to do this.

By possibility you mean to change the behavior? I then assume that reflection cannot distinguish between "own" and promoted methods. Is that correct? If so, then maybe a separate issue for adding such feature to the reflect package should be filled. Any opinion about this?

Personally I think your doc suggestion adds too much text and in the wrong place. This kind of discussion seems more appropriate in a discussion of embedded types, as it is not specific to encoding/gob. For example, it comes up more often in the way that the fmt package handles the String method.

Yes, I meant that as far as I know the reflect package can not distinguish directly implemented methods and promoted methods. I don't think such a feature should be added. In general, the reflect package implements what the language implements, and in the language promoted methods are the same as methods defined directly on the type.

I'll add that I'm sorry you got bitten so badly by this. It is a corner of the language that can catch people by surprise. But if better docs are needed, let's make sure to put them in the right place.

Gob lesson learned and learning new things is always good, no problem here. Thank you for taking the time to reply.