All committers have signed the CLA.

It would help other users if we could document our guidelines for ensuring proto2 and proto3 compatibility (as well as compatibility across different languages in case it makes a difference). My understanding (for this PR) is the following, is this correct? DO NOT use the has_foo() method for any field "foo" of primitive or enum types; it is treated as being present with a default value (if absent in the serialized representation). However, for all the non-primitive types (which are always declared optional in ONNX) as well as oneof fields, it is safe to use the "has_foo" method. Is this correct?

It would help other users if we could document our guidelines for ensuring proto2 and proto3 compatibility (as well as compatibility across different languages in case it makes a difference). My understanding (for this PR) is the following, is this correct? DO NOT use the has_foo() method for any field "foo" of primitive or enum types; it is treated as being present with a default value (if absent in the serialized representation). However, for all the non-primitive types (which are always declared optional in ONNX) as well as oneof fields, it is safe to use the "has_foo" method. Is this correct?

To be a little more specific. The reason we are able not to use has_*() on the primitives is because when we assign a value to them we also set the enum. So if enum is not set then it is UNDEFINED (0) by default, otherwise simply read the primitive type because we know the value is correct. This works when primitives are intentionally paired with enums and 0 means UNDEFINED. There are comments in the proto files to that effect.

We also do not want to use has_*() on oneof fields because in that case proto compiler automatically generates a corresponding enum. That enum value can tell us which field is set if any.

Otherwise, we can use has_*() providing we are built with proto2 library. proto3 compiler does not generate has_*() methods, which would become an issue if we migrated to proto3.

@houseroad Can you, please, be a bit more specific as to what you mean to change existing CI to proto3? Current code will not compile with proto3 interfaces, mostly because of the extensive use of has_*() methods. So that would call for refactoring. However, changing to proto3 would require even more discussions. I am trying alleviate a specific pain point where compatibility is required.