Simple things like this will up being useful: func Clone[T proto.Message](in T) T { return proto.Clone(in).(T) } (proto.Clone(&somepb.MyMessag

Simple things like this will up being useful: func Clone[T proto.Message](in T) T { return proto.Clone(in).(T) } (proto.Clone(&somepb.MyMessage{...}) normally returns a proto.Message, but this returns a *somepb.MyMessage, which is nice.) I think we'll find reasonable uses all over the place. The place where I most want it is in the k8s client-go. All of the Reflector/Informer code I've written starts every event reception handler with a typecast of a v1.Object into the actual object you care about. With generics, that type checking can be done for you in advance. (I haven't thought about how all the codegen will be affected. Right now something like client.CoreV1().Secrets().List() returns a well-typed SecretList; return value dot Items's type is Secret, not Object. Obviously generics can do the same thing, the question is whether or not it's worth it when you already generate the necessary wrappers and "generic methods" anyway.)