all: decide what can implement TextMarshaler/TextUnmarshaler

[lavalamp]

For example, the standard library has a decent encoding/json package, and a great time.Duration object. But these objects don't play well together; if you want to encode a Duration in a json blob, you'll have to make a custom type that calls .String()/ParseDuration() when Get/SetJSON are called. It would be nice if they worked together by default.

...Unfortunately, the cross product of all the useful encoding packages with all the useful types in the standard library is probably quite large, so I'll understand if you say "no" to that. Perhaps at least time.Time and time.Duration could be supported?

[rsc]

This isn't possible to change now, as it would change the encodings produced by programs that exist today.

[lavalamp]

@rsc Let me push back just a little on that, I don't see why it's necessarily true.

For example, again taking encoding/json with time.Time & Duration: I don't see a reason why the time.SetJSON method couldn't accept as input the string that's currently emitted.

I can see why you'd want to change the output of time.Duration, but I'm not sure why it'd be a problem to make the SetJSON method accept both the new output format (e.g., "5s") and the old (which is nanoseconds, without quotes). Those cases are super easy to distinguish.

...I agree the generalized cross product of types w/ encodings is probably going to have many much more difficult cases.

[rsc]

Replying to a comment from 2015, but we can't change the encoding outputs now because then if a new version of Go is sending data to an older version, the older version will not understand it.

[lavalamp]

That means it'd have to be opt in, e.g. with paired type TextMarshaller2 interface { ... V2() } and json.NewEncoder().UseV2().Encode(). Obviously that's hideous and I don't think it should be done, but it is possible.

[rsc]

It means it would have to wait for Go 2.

[ianlancetaylor]

If we change this in Go 2--if we add marshaling methods for standard library types--we will have to provide some mechanism for Go 2 programs to read Go 1 data. One approach would be to only add marshaling methods in new versions of the packages, and to permit the old and new versions of the package to both be imported in the same program.

[aviau]

we can't change the encoding outputs now

@rsc Would you consider implementing Unmarshal interfaces?

We can do this right now, can't we?

#25705 Was closed because apparently implementing UnmarshalText in net/url would break existing code. Maybe I am missing it, so please correct me if I am wrong, but I don't see how that is true.

There are plenty of use cases for code that parses URLs and this seems like an easy fix.

[andig]

@rsc Would you consider implementing Unmarshal interfaces?

Ping @rsc would that be possible without breaking compatibility?

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[gopherbot]

Change https://go.dev/cl/496537 mentions this issue: encoding: document when marshaling methods can be added