Should be possible to deserialize unknown enum values

[torkelrogstad]

Consider the following Proto file:

message Foo {
  MyEnum my_enum = 1;
}

enum MyEnum {
  MY_ENUM_UNSPECIFIED = 0;
  MY_ENUM_BAR = 1;
  MY_ENUM_QUX = 2;
}

I'm interested in receiving JSON-encoded Foo messages where the enum might have more values added to it later, without me having to update my Proto file and re-generate code. Both of these JSON blobs deserialize fine: {"myEnum": "MY_ENUM_UNSPECIFIED"} and {"myEnum": 1}. However, these two won't work: {"myEnum": "MY_ENUM_BUX"} and {"myEnum": 100}.

It would be great if some sort of mechanism could be added to tolerate unknown enum values.

[efer-ms]

So I ran into this today. It really destroys the forward-compatiblity of protobufs. AFAICT, this can be remedied easily, at least for JSON with numeric values, as rather than trying to deserialize into the Enum type, we should be able to simply store the numeric type from the JSON. Then it works the same a deserializing binary protobuf... the i32 representation is there, but the enum value will be UNSPECIFIED/UNKNOWN.

Would it be reasonable to make this an option to the builder, similar to ignore_unknown_fields, some sort of allow_unknown_enum_values()?

For string mapping, we'd lose the provided identifier but can still set the field to 0.

I can take a stab at making this a feature if this sounds reasonable.