Joshua Humphries

Okay. I have a branch where I am just embedding the protoreflect interface, so that my type makes the Go compiler happy. I guess I'm wondering how likely I am...

> Is this "don't yet" because you haven't implemented it yet, or because at this stage of parsing the descriptors haven't been created yet? @neild, at this stage of parsing,...

@maguro, I'm a little confused that what you are describing, as well as the PR (#6078) is about adding a _new_ syntax for multi-line string literals in the protobuf **source...

> Unmarshal from a FileDescriptorSet created with protoc (but this has the above chicken-or-egg problem with proto.Unmarshal). Java has supported descriptors and dynamic messages and extension registries for ages, but...

Maybe I could create a APIv2 compatibility package -- with its own `go.mod` file (so the main protoreflect `go.mod` can still refer to pre-v1.4 runtime, so users aren't forced to...

To be clear, when I say "re-parse", I don't mean parsing source (which I suspect is 90% of the time in buf). I mean parsing the binary format. But, the...

I received several bugs against protoparse related to handling of message set wire format. So _someone_ is using it: * https://github.com/jhump/protoreflect/issues/275 * https://github.com/jhump/protoreflect/issues/308

FWIW, I believe it is possible (likely even?) that teams _inside_ of Google use protoparse. Also, as mentioned in the description, this is strangely inconsistent. I can generate such code...

I have a repo that attempts to be a pure Go replacement for protoc. It only deals with descriptors. It would be a rather huge shame if I were unable...

> I should note that legacy features like MessageSets and weak fields are guarded by the protolegacy build tag. Are you suggesting that I should just build with this tag,...