net/url: Userinfo should support encoding/gob

[chowey]

Currently the encoding/gob package does not support embedded structs with no exported fields. See #5819.

This is problematic for the net/url package. I cannot serialize a url.URL into a gob because url.Userinfo has no exported fields. I can't be the only one who has needed to serialize a struct with a URL in it.

This is solvable without modification to the encoding/gob if we fix url.Userinfo. This is possible by implementing encoding.BinaryMarshaler and encoding.BinaryUnmarshaler:

func (u *Userinfo) UnmarshalBinary(data []byte) error {
    return nil
}

func (u *Userinfo) MarshalBinary() (data []byte, err error) {
    return nil, nil
}

[bradfitz]

Or perhaps encoding/gob should let you register marshal/unmarshal funcs for a given concrete type yourself, then net/url can remain happily oblivious of gob.

/cc @robpike

[nightlyone]

Implementing encoding.BinaryMarshaler and encoding.BinaryUnmarshaler seems very sane to me, since it solves that problem for other binary encodings, too. Please remember that the generic marshaler/unmarshaler support in package encoding has been introduced exactly to solve those problems in a generic way and per type that needs it.

[rsc]

If we're going to do something for url.URL, why not give URL MarshalText/UnmarshalText methods instead? Why work on this tiny piece of the URL instead of the whole thing?

That said, we have to proceed very carefully here because of backwards compatibility concerns. It may not happen for 1.6.

[chowey]

This works too. MarshalText could call URL.String, and UnmarshalText could call url.Parse. It is very straightforward.

How would this break backward compatibility? If someone is relying on the fact that url.URL cannot be marshaled or unmarshaled?

[rsc]

@chowey It's a change in behavior. It can surprise people. And if it can, it will. We've struggled with this when adding custom encodings for other types as well.

[gopherbot]

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