proposal: net/url: implement TextMarshaler/TextUnmarshaler interfaces for url.URL

[YaroslavDev]

In order to be able to pass url.URL variable to flag.TextVar(&url, ...), url.URL type must implement encoding.TextMarshaler and encoding.TextUnmarshaler interfaces.
This approach was suggested here instead of making a dedicated flag.URLVar function in flag package.

[earthboundkid]

I think this would be good, but is it a breaking change? Right now, the output of this code

	u, _ := url.Parse("http://example.com")
	b, _ := json.Marshal(u)
	fmt.Println(string(b))

is

{
 "ForceQuery": false,
 "Fragment": "",
 "Host": "example.com",
 "Opaque": "",
 "Path": "",
 "RawFragment": "",
 "RawPath": "",
 "RawQuery": "",
 "Scheme": "http",
 "User": null
}

I think it would be better if the output were "http://example.com" but maybe someone somewhere would miss the old output?

[YaroslavDev]

@carlmjohnson nice catch!
I guess there are 2 options:

1. Make a breaking change since url.URL typically is not used as JSON(maybe only for debugging/logging purposes)
2. Implement explicitly json.Marshaler and json.Unmarshaler interfaces on url.URL as well to maintain backward compatibility

[YaroslavDev]

what are next steps for this? should I wait for more comments/suggestions/concerns?
should I wait for proposal to become accepted before I can implement it?
thank you.

[seankhliao]

Proposals need to be accepted before the change will be accepted, see proposal-process

[earthboundkid]

If you have spare time you could implement it now, but it won't be reviewed and merged until after the proposal has been approved and the code tree is open. This is a quiet week for the Go team: https://groups.google.com/g/golang-dev/c/EDstQLuReWE/m/s7bR1dfmAQAJ After the quiet week, the proposal will probably be formally evaluated and eventually get a decision in a few weeks. There's a proposals team that looks at the open proposals and moves them towards a decision, although it can vary exactly how long that process takes. (See https://github.com/golang/proposal.) Once that happens, assuming the proposal is accepted, a commit can be accepted and merged during the next "development work" phase of the release cycle. (See https://github.com/golang/go/wiki/Go-Release-Cycle.) That won't be until August, unfortunately.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

It seems like JSON decoding the { } form might still work since that's not a JSON string, so it won't try the TextUnmarshaler. So an old encoding might be readable by a new Go where URL implements these methods. The reverse would not be true.

Have we decided before whether this is OK? I seem to remember JSON encoding of IP addresses used to be base64 byte encodings, but I think we decided that was just so broken we could fix it.

Not changing the JSON seems like a big inconsistency too since I assume the goal here is to get better JSON support for URLs (in addition to flag support).

[seankhliao]

It seems like JSON decoding the { } form might still work since that's not a JSON string, so it won't try the TextUnmarshaler.

encoding/json currently doesn't have that kind of fallback: https://go.dev/play/p/z8QXBU6Ov2z

json: cannot unmarshal object into Go value of type *main.New

---

Have we decided before whether this is OK?

#5086 for net.IP: done in go1.2
#10244 for net.HardwareAddr: declined for no standard format
#10275 for stdlib types in general: undecided
#12803 for net.IPNet: Not ok
#16039 for time.Duration: declined for no standard format
#24174 for time.Duration: folded into #10275
#25705 for url.URL: folded into #10275
#29678 for net.HardwareAddr: undecided
#40436 for net.IPMask: no comments

[rsc]

Thanks very much for that list, @seankhliao! It looks like we should merge this one into #10275 too, and then bring 10275 over to the non-Go2 proposal process.

[rsc]

This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group