4 ms·

When the deserializing half of the protobuf definitions encounter an unknown value, it gets deserialized as the zero value. When that client updates, it will th

When the deserializing half of the protobuf definitions encounter an unknown value, it gets deserialized as the zero value. When that client updates, it will then be able to deserialize the new value appropriately (in this case, "Mint"). The advice on that page also specifies to not make the value semantically meaningful, which I take to mean to never set it to that value explicitly.

chen_dev 2y ago
> it gets deserialized as the zero value It’s more complicated: https://protobuf.dev/programming-guides/enum/ https://protobuf.dev/programming-guides/enum/ >> What happens when a program parses binary data that contains field 1 with the value 2? >- Open enums will parse the value 2 and store it directly in the field. Accessor will report the field as being set and will return something that represents 2. >- Closed enums will parse the value 2 and store it in the message’s unknown field set. Accessors will report the field as being unset and will return the enum’s default value.
- vitus 2y ago
  Ugh. I hate how we (Google) launched proto editions. It used to be that we broadly had two sets of semantics (modulo additional customizations): proto2 and proto3. Proto editions was supposed to unify the two versions, but instead now we have the option to mix and match all of the quirks of each of the versions. And, to make matters worse, you also have language-dependent implementations that don't conform to the spec (in fact, very few implementations are conformant). C++ and Java treat everything imported by a proto2 file as closed; C#, Golang, and JS treat everything as open. I don't see a path forward for removing these custom deprecated field features, or else we'd have already begun that effort during the initial adoption of editions.
dwattttt 2y ago
> The advice on that page also specifies to not make the value semantically meaningful, which I take to mean to never set it to that value explicitly. I've taken to coding my C enums with the first value being "Invalid", indicating it is never intended to be created. If one is encountered, it's a bug.

chen_dev 2y ago

> it gets deserialized as the zero value It’s more complicated: https://protobuf.dev/programming-guides/enum/ https://protobuf.dev/programming-guides/enum/ >> What happens when a program parses binary data that contains field 1 with the value 2? >- Open enums will parse the value 2 and store it directly in the field. Accessor will report the field as being set and will return something that represents 2. >- Closed enums will parse the value 2 and store it in the message’s unknown field set. Accessors will report the field as being unset and will return the enum’s default value.

vitus 2y ago
Ugh. I hate how we (Google) launched proto editions. It used to be that we broadly had two sets of semantics (modulo additional customizations): proto2 and proto3. Proto editions was supposed to unify the two versions, but instead now we have the option to mix and match all of the quirks of each of the versions. And, to make matters worse, you also have language-dependent implementations that don't conform to the spec (in fact, very few implementations are conformant). C++ and Java treat everything imported by a proto2 file as closed; C#, Golang, and JS treat everything as open. I don't see a path forward for removing these custom deprecated field features, or else we'd have already begun that effort during the initial adoption of editions.

dwattttt 2y ago

> The advice on that page also specifies to not make the value semantically meaningful, which I take to mean to never set it to that value explicitly. I've taken to coding my C enums with the first value being "Invalid", indicating it is never intended to be created. If one is encountered, it's a bug.