Comment 2:

A related issue: I believe this program should print {}, not {"X":null}.
It may be strictly speaking within the letter of the documentation
(the interface is not nil, but holds a nil value) but
I think it would be more in the spirit of the existing marshalling
(and consistent with encoding/xml) for the value inside the interface
to be considered when deciding about omitempty.
package main
import (
    "encoding/json"
    "fmt"
)
type Foo struct {
    X interface{} `json:",omitempty"`
}
func main() {
    data, err := json.Marshal(Foo{[]int(nil)})
    if err != nil {
        fmt.Println("err: %v", err)
    } else {
        fmt.Printf("%s\n", data)
    }
}

Comment 3 by krolaw:

I like that json does not look inside the value of the pointer.  Otherwise, I wouldn't
be able to set the difference between a zero (zero availability) and null value (no
update), which is important in the motel management solution I am writing.
Maybe omitempty is too general.  Maybe we need an omitnil as well.

Comment 4:

Labels changed: added priority-later, go1.2maybe, removed priority-triage.

Status changed to Accepted.

Comment 5:

Labels changed: added feature.

Comment 6:

Not for 1.2.

Labels changed: removed go1.2maybe.

Comment 7:

Labels changed: added go1.3maybe.

Comment 8:

Labels changed: removed feature.

Comment 9:

Labels changed: added release-none, removed go1.3maybe.

Comment 10:

Labels changed: added repo-main.

What's the status on this ticket ? it's really hurting development , as it basically means for all google APIs (that use SOAP, and hence XML) we have to throw away the default xml marshaling and roll out our own :/

@allan-simon, the status is that nobody is working on it.

@bradfitz ok ^^' , if I was to try my hand on it, would it have chances to get merge (admitting i follow the correct contributing procedure ofc) ? By that I mean, would there be backward compatibility concerns, even though it's not a documented "feature" ?

I think it has a good chance of being accepted. If not it would've been closed a long time ago as "Unfortunate". The fact that it's still open implies that some sort of fix is possible. It's also not labeled as a "Documentation" fix. So, give it a shot. Complications often arise during development, but try and see.

@bradfitz , thanks for the clarification , if things get complicated I will expose them here

after investigation the problem seems to be with https://github.com/golang/go/blob/master/src/encoding/xml/marshal.go#L762-L768
which mean that when we got a struct with a field which is a pointer to an empty string, we already call "marshalValue" with the empty string, rather than the pointer

So when we arrive in the function, we early return https://github.com/golang/go/blob/master/src/encoding/xml/marshal.go#L405-L407 as we got an empty string
but deferencing should be the job of https://github.com/golang/go/blob/master/src/encoding/xml/marshal.go#L409-L417

I've added in marshal_test for OmitFieldTest struct a field "PStr" which is a *string, and in the test, initialized it to a pointer to an empty string, with current code it fails, by removing lines 762-768 it works

but now one test fail

--- FAIL: TestMarshal (0.00s)
    marshal_test.go:1030: #76: marshal(&xml.PointerFieldsTest{XMLName:xml.Name{Space:"", Local:""}, Name:(*string)(0x703100), Age:(*uint)(0x6f5158), Empty:(*string)(nil), Contents:(*string)(0x7030e0)}):
        have `<dummy name="Sarah" age="12"></dummy>`
        want `<dummy name="Sarah" age="12">lorem ipsum</dummy

I will dig more in some hours after some sleep ^^

got it, it was because the chardata / attributes part were relying on the fact that pointer were already dereferenced by the calling function, so it was simply ignoring pointers

all test are passing now, I will complete the test suite that was lacking some cases and i will issue a patch

I made a patch :) https://go-review.googlesource.com/#/c/15684/

CL https://golang.org/cl/15684 mentions this issue.

However, json does not look at the value behind pointers, while xml does. This
difference is made obvious when wanting to omit nil pointers, but retain empty values.

Oh yes. The most important consequence of this for me is a problem with bool types. If I have type Bool bool, then MarshalXML defined on Bool is called for &Bool(true), but not for &Bool(false).