Joe Tsai

Seems reasonable, but adding new API is a decision for the current maintainers of this module.

While we ensured flexibility of possibly adding options specifically for `protocmp.Transform`, I'm not sure if it will make it more or less confusing for user that some options are for...

Actually, the above could probably slightly simplified as: ```go func [M proto.Message, V any] TransformMessage(f func(M) V) cmp.Option { var m M md := m.ProtoReflect().Descriptor() return FilterMessage(md, cmp.Transformer(m1 Message) V...

As an aside, we could probably add a `protocmp.Message.Unwrap` method that returns the original concrete message value. That would avoid a conversion. EDIT(2021-08-06): Sent https://go-review.googlesource.com/c/protobuf/+/340489 to add `protocmp.Message.Unwrap`.

I'd be happy to review, but you'd need to submit it through Gerrit first. If you're not aware, there's a contribution guide at: https://go.googlesource.com/protobuf/+/refs/heads/master/CONTRIBUTING.md The protobuf module uses a very...

I've been using the `dev.fuzz` branch of the Go toolchain and it's quite a bit easier to use since it's natively integrated into the Go toolchain itself. Given that golang/go#44551...

Is there any real code outside Google that actually uses MessageSet? It's an artifact of proto1 and it's a source of significant technical debt. In open-source, we ideally should treat...

> Also, as mentioned in the description, this is strangely inconsistent. I can generate such code to Go using protoc-gen-go and load the descriptor just fine. I agree it's inconsistent,...

> Protobuf enums already follow C++ scoping rules though so this seems unnecessary as you should be guaranteed of not having a collision within a single package. This is not...

I proposed `go_name` in #555 as an alternative to `goproto_enum_prefix`. It's more work specifying it on each value, but it is more generalizable to a number of different use cases....