Consider deprecating omitzero in favor of a more general omitempty

[cespare]

It would be better if omitempty handled a variety of zero values -- including for numeric types -- as encoding/json does, rather than having a separate omitzero concept.

[bbuck]

What if the zero value is acceptable but given a pointer nil means it should be left out.

[cespare]

@bbuck I don't understand what you're saying about "zero value is acceptable".

I opened #124 to extend omitempty to handle nil values of pointer and interface type.

[bbuck]

Must have misunderstood your original wording.

On Wednesday, March 2, 2016, Caleb Spare [email protected] wrote:

@bbuck https://github.com/bbuck I don't understand what you're saying
about "zero value is acceptable".

I opened #124 #124 to extend
omitempty to handle nil values of pointer and interface type.

—
Reply to this email directly or view it on GitHub
#120 (comment).

[arp242]

The problem with changing this now is that it's an incompatible change; what if people have omitempty on their existing structs but that have no effect? Silly thing to do, perhaps, but just changing the behaviour strikes me as having the potential to cause a lot of confusion and problems.

If this was written today: yeah, this would obviously be the correct way to do it. But now we're kind of stuck with it until we do a v2 (if ever).

[arp242]

The JSON "omitzero" proposal was accepted: golang/go#45669 :

// The "omitzero" option specifies that the field should be omitted
// from the encoding if the field has a zero value, according to rules:
//
// 1) If the field type has an "IsZero() bool" method, that will be used to
// determine whether the value is zero.
//
// 2) Otherwise, the value is zero if it is the zero value for its type.
//
// If both "omitempty" and "omitzero" are specified, the field will be omitted
// if the value is either empty or zero (or both).