Support the standard marshaling/unmarshaling interfaces from the encoding
package:
Is this considerably different from the support that already exists for TextMarshaler/TextUnmarshaler?
What use cases does this have?
This means supporting types that implement that interface. The support for types that implement a different interface won't make that work.
This is specifically useful for url.URL
due to it's inability to implement encoding.TextUnmarshaler
until Go 2:
I might take a crack at this.
The same problem reported as a breakage there also looks like an issue for yaml.
It's a bit of an awkward choice to trust on the binary encoding of the type to present a nice textual representation. I wonder if it will backfire in other cases, where we'd otherwise get a pleasant representation of the fields, and now get some unreadable binary blob.
We might support BinaryMarshaler/Unmarshaler in v3 before it's final, but we'll need to first have a look to understand what the most common conventions are around it.
To echo @lrewega, this would be very useful for url.URL
support.
@niemeyer v3 landed a few months ago, what are your thoughts on the issue?
ping @niemeyer . This has been a long outstanding issue, what are your thoughts on adding support for this?
Any reason _not_ to add this?
Most helpful comment
The same problem reported as a breakage there also looks like an issue for yaml.
It's a bit of an awkward choice to trust on the binary encoding of the type to present a nice textual representation. I wonder if it will backfire in other cases, where we'd otherwise get a pleasant representation of the fields, and now get some unreadable binary blob.
We might support BinaryMarshaler/Unmarshaler in v3 before it's final, but we'll need to first have a look to understand what the most common conventions are around it.