You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to propose a command line parameter for the generator like "receiver-preference" or similar to modify the receiver logic for Marshal and MsgSize methods. So it could either do:
Pointer receivers for everything
Pointer receivers for unmarshal methods, but non-pointer receivers for marshal methods (this might also satisfy a previous issue)
Dynamic like before
Currently the generator will frequently mix receiver types for generated methods. This causes annoyances in some scenarios like for example when using both the Unmarshaler and Marshaler interfaces in another custom interface. Since generated types often don't implement both of these interfaces at once, the custom interface might also become unusable.
Currently you could work around this by including unexported and omitted fields in the struct to fool the generator into using pointer receivers:
//go:generate msgp -unexported
type MyCustomType struct {
forcePtrRcvr struct{} `msg:"_,omitempty"`
ArbitraryField int
}
But this is unclean and doesn't work when encoding to tuples using //msgp:tuple MyCustomType, when using basic types (not structs) or when unexported fields should not be serialized at all.
Let me know what you think and if I can provide further information or assistance :)
The text was updated successfully, but these errors were encountered:
I'd like to propose a command line parameter for the generator like "receiver-preference" or similar to modify the receiver logic for Marshal and MsgSize methods. So it could either do:
Currently the generator will frequently mix receiver types for generated methods. This causes annoyances in some scenarios like for example when using both the Unmarshaler and Marshaler interfaces in another custom interface. Since generated types often don't implement both of these interfaces at once, the custom interface might also become unusable.
Currently you could work around this by including unexported and omitted fields in the struct to fool the generator into using pointer receivers:
But this is unclean and doesn't work when encoding to tuples using
//msgp:tuple MyCustomType
, when using basic types (not structs) or when unexported fields should not be serialized at all.Let me know what you think and if I can provide further information or assistance :)
The text was updated successfully, but these errors were encountered: