lfolger

Hi ofen, Sorry for the late reply. I think to design a generic solution for such a problem is a large task and requires a lot of design work to...

I agree that the double iteration approach is more expensive than if there were hooks directly in the encoder. If performance is critical to you, json might not be the...

@Olex1313 this would require us to exposse the encoder because it is used in the code 228+. This is a quite large change and I don't think we can do...

To be able to analyze this issue, could you provide steps to reproduce the issue? From the stacktrace itself it is not immediately clear what the issue is.

>The main issue will be with supporting the user providing a custom/modified/etc version of google/protobuf/descriptor.proto. Does this mean you are allowing users to redefine the descriptor proto includings feature defaults?...

Thanks for clarifying. I think I misunderstood what you said initially. It seems this is limited to released version of the descriptor.proto not arbitrary modifications to the descriptor proto. And...

Could you explain your use case in more detail?

>For both of the examples I gave above there isn't really a way to achieve the developer experience we want without changing the generated code. I don't think is true....

In general we moved away from struct tags in favor of protoreflect API. In the deprecated protobuf module we used struct tags to build limited reflection mechanisms. However, this turned...

Also I realized that edition features are not designed for this. While they can certainly be (ab)used for this it is not the intention to use them this way. From...