-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add a generic proto.Clone #1594
Comments
We discussed this internally and more or less aligned on // CloneOf returns a deep copy of m. If the top-level message is invalid,
// it returns an invalid message as well.
func CloneOf[M Message](m M) M {
return proto.Clone(m).(M)
} We decided to not move forward with it because at the time some of the tooling we use internally wasn't ready for generics. The remaining difficulty is that we are still supporting go 1.17, but we can work around that with build tags. We're happy to accept a contribution. :) Regarding |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Use of
proto.Clone
is awkward because it returns aproto.Message
, even though the caller often has a concrete type in hand. In those cases, working with the cloned message requires a type assertion and (more importantly) error handling. For example:The error-handling path is unnecessary -
Clone
always returns a*timestamppb.Timestamp
, but that isn't visible to the type system. Of course, the caller can instead panic if the type assertion fails...but modern Go offers a more palatable option.Describe the solution you'd like
Now that generics are available in all supported Go versions, it'd be nice to have a type-safe, generic variant of
proto.Clone
:Then our example code becomes:
Virtually all implementations of
proto.Message
are pointers to structs and have the same gcshape, so use of this generic function shouldn't significantly affect binary size (at least, with the current generics implementation).The new function could be called
DeepCopy
,CloneMessage
,CloneT
, or whatever else seems appropriate.DeepCopy
feels the most natural to me, since it's how the current GoDoc describe'sClone
's behavior.Describe alternatives you've considered
Clone
use type assertions. This is fine, but why not offer a nicer API now that we can?DeepMerge
andDeepEqual
as generic equivalents ofMerge
andEqual
. I'm in favor of this, but perhaps we should discuss in a separate issue?Additional context
I'm happy to open a CL for this if we can agree on naming.
The text was updated successfully, but these errors were encountered: