Joshua Haberman

On the other hand you're not the first person to ask for this. Here is another: https://github.com/google/protobuf/pull/4385 Let me poll a few other people and see what they think.

I agree that there is no reason not to accept RepeatedField/Map in the constructor. Let me write a change to do that part.

Sorry for the long inactivity on this issue. I agree that we should fix it, in both cases (constructor and assignment). There is one unresolved question in my mind. Suppose...

This is supported at the upb level: https://github.com/protocolbuffers/upb/blob/ada907989e075658b72a6dcb3ec8335b43596cbc/upb/json_encode.h#L48-L49 It would be an easy change to plumb this through the Ruby layer, in addition to the existing options: https://github.com/protocolbuffers/protobuf/blob/7309e8882cb81a92cee4b0be708a61c8f4707224/ruby/ext/google/protobuf_c/message.c#L1146-L1155

Blocked by: https://github.com/protocolbuffers/protobuf/issues/9495

You are correct that Ruby does not yet support custom options. Hopefully we can add this before too long.

This is becoming a more and more common request. I have been thinking through how the implementation ought to work on this. It's slightly tricky to modify the DSL for...

Ok there are a couple parts to making this work. First of all we need to support proto2 field presence. Right now the code generator fails immediately if it sees...

Custom options are defined as extensions of messages `descriptor.proto`, which is a `syntax="proto2";` file. Extensions don't exist at all in proto3. So even if your messages are only proto3, we...

I'm sorry this has been frustrating to track down. I was not able to reproduce your report of getting different output from `protoc-3.17.3-linux-x86_64.zip` and `protoc-3.17.3-osx-x86_64.zip`. I tried them both just...