New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: encoding/binary: let Write and Read recognize common interfaces #29222
Comments
To be specific, it sounds like you are suggesting that we add these lines to start of if m, ok := data.(encoding.BinaryMarshaler); ok {
data, err := m.MarshalBinary()
if err != nil {
return err
}
_, err := w.Write(data)
return err
} Also add similar lines to This doesn't seem too useful at top level, since you could just do that yourself. In particular I don't see how it helps your example. You would not be able to implement the The place where this could be useful is when you have a struct containing some fields that |
Also I note that the possibility that some types implement their |
Or some equivalent, yes.
Could you expand on this? I for sure can handle each field myself, but again that's time-consuming and error-prone.
The method name (
This proposal could definitely be interface independent as well. It's not married to (PS: same person, different GitHub account.) |
At top level you can just do your own check for |
This is an API change and a potentially breaking one, so turning it into a proposal. |
That doesn’t scale well, though. The biggest benefit to Imagine if |
I've updated the proposal to make it more succinct and clarified unclear parts. |
The doc comment for this package says:
Everything about Read and Write is meant for fixed-size values, not arbitrary values with custom marshalers and so on. It looks like I did say in 2010 that I would be interested in proposals to extend that, but at this point it seems like binary is doing well as is and that more advanced uses should go to json or gob or something else. Let's not add more complexity here. |
Proposal: let binary.Write and binary.Read recognize common interfaces
Author(s): Eric Lagergren
Last updated: 2018-12-14
Abstract
Currently,
binary.Write
andbinary.Read
rejects struct fields, array elements, and top-level slices that don't have a fixed length. This limitation can make serializing structs time-consuming and error-prone. This proposal would remove this limitation, provided the non-fixed length type implements one of two interfaces.Background
Attempting to use
binary.Write
orbinary.Read
to (de)serialize a struct, array, or top-level slice that contains a non-fixed length type (for example,[]byte
) as a field or element results in an error. This is explicitly stated in the docs:Example 1, struct.
Example 2, array.
I originally encountered this limitation when I needed to use an API that required serialized structs. For example:
Since
T.Data
does not have a fixed length, the call tobinary.Write
results in an error.In order to serialize
T
, I have to create a custom method:This specific case (
T
) is quite simple. However, I have at least 5 other types, some of which look like this:Creating a
serialize
method forG
is time-consuming and error-prone:Proposal
I propose we add two interfaces that allow user-specified encodings to and from
[]byte
for types that don't have a fixed length.We need not use an already-existing interface, but
encoding.BinaryMarshaler
andencoding.BinaryUnmarshaler
are good candidates.Rationale
This proposal provides a simple way to serialize more complex structs, arrays, and top-level slices—something that has historically been time-consuming, error prone, and/or required code generation.
Compatibility
The change is Go 1 compatible if the interfaces are only checked after determining that the type does not have a fixed length. This is similar to: #12146
Implementation
TBD
Open issues (if applicable)
This idea has been mentioned before by Russ: #478 (comment)
The text was updated successfully, but these errors were encountered: