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
With the generics approach, all methods share the same name, but my have different types that it operates on. Perhaps this is a feature since it forces a given type to only implement MarshalScalar for one type. We wouldn't have to define the behavior for when MarshalInt and MarshalUint are both present.
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
common interfaces for arshaling primitive kinds
common interfaces for marshaling primitive kinds
Oct 12, 2022
The inspiration for this is #54582.
Adding
MarshalJSON
methods would work, but is not performant since we would always be allocating, which is unfortunate.Alternative, these types could implement:
However, this would cause the
atomic
package to have a dependency on both thejson
andjsontext
packages, which is unreasonable.I wonder if we should support something like:
Alternatively, we could even have:
With the generics approach, all methods share the same name, but my have different types that it operates on. Perhaps this is a feature since it forces a given type to only implement
MarshalScalar
for one type. We wouldn't have to define the behavior for whenMarshalInt
andMarshalUint
are both present.The text was updated successfully, but these errors were encountered: