json (or xml) marshalling, omitempty, and zero values

[Will Norris]

I recently hit a problem with my go-github library where I'm unable to set values to their zero value, since they are defined with omitempty and they get dropped when marshalling the JSON (full GitHub issue here).  The obvious answer seems to be to use pointers for my struct fields, especially since that's what goprotobuf uses.  My two questions are:

1) In my (certainly non-exhaustive) perusal of various go libraries, this pattern does not seem to be very well adopted.  Clearly, some of that may be cases where there isn't a need to explicitly set a field to it's zero-value.  But certainly, I would have expected to see this more.  Am I just not looking in the right places, and this is more common than I think it is?

2) If it is a more common pattern, would it make sense to promote proto.String() and friends to a more general location?  What are other libraries doing for this (creating pointers to primitive types)?  Are they redefining those helper functions, importing goprotobuf just for those helpers, not using helpers at all?

[David Symonds]

It sounds like it's a fairly messy JSON protocol. What about
implementing the json.Marshaler interface on the type and doing the
relevant custom logic via packing into a temporary
map[string]interface{}?

[Will Norris]

It's not really just at the JSON level... even if I were to write my own json.Marshaler implementation, I don't know whether the caller of my library intended to update a particular field to be an empty string, for example, or whether they meant for the existing value to be left as-is.  GitHub does a partial update, so there is a definite semantic difference between sending them an empty string versus omitting that field.  With the HTTP PATCH method, that's not all that uncommon in REST APIs.