Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
encoding/gob: ignore func and chan values during encoding #6071
We have been assuming that we can add new fields to existing structs as long as the zero value of the field means "the old behavior". This is not strictly true for gob, because the new field may contain a type that will cause gob to reject a struct that it formerly accepted. I ran across this because I added a Client *http.Client to a struct that I had forgotten was being gob-encoded, and http.Client contains a func-valued field, which caused gob to refuse to encode any instance of that struct. I am not sure what, if anything, we should do, but I wanted to record the fact as something we should think about. It would be good to find some way to avoid making existing gob-compatible structs gob-incompatible in future releases. Perhaps the API tool should reject new additions of gob-incompatible fields, although that determinination requires recursive traversal of the content of the type of the new field. Perhaps gob should change to be more lax. It's unclear.
Perhaps gob should just be more forgiving. I thought there was a bug filed about this but there's only one about nested unmarshalable structs, which is a separate issue. I propose that gob treat chan and func fields exactly as it now treats unexported fields. If there is no custom encoder for that field, it is simply ignored. It's an easy, backwards-compatible change that will take care of a large subset of the compatibility issue.