This gist of the new test case coverage can be summarized as: - The wire does not distinguish between explicit and implicit fields. - For implicit presence fields, zeros on the wire can overwrite nonzero values (i.e. they are treated as a 'clear' operation). It's TBD whether we want to accept this behaviour going forward. Right now we are leaning towards keeping this behaviour, because: - If we receive zeros on the wire for implicit-presence fields, the protobuf wire format is "wrong" anyway. Well-behaved code should never generate zeros on the wire for implicit presence fields or serialize the same field multiple times. - There might be some value to enforce that "anything on the wire is accepted". This can make handling of wire format simpler. There are some drawbacks with this approach: - It might be somewhat surprising for users that zeros on the wire are always read, even for implicit-presence fields. - It might make the transition from implicit-presence to explicit-presence harder (or more unsafe) if user wants to migrate. - It leads to an inconsistency between what it means to "Merge". - Merging from a constructed object, with implicit presence and with field set to zero, will not overwrite. - Merging from the wire, with implicit presence and with zero explicitly present on the wire, WILL overwrite. I still need to add conformance tests to ensure that this is a consistent behavior across all languages, but for now let's at least add some coverage in C++ to ensure that this is a tested behaviour. PiperOrigin-RevId: 657724599pull/17648/head
parent
6ab302d3a3
commit
06a520cdb7
3 changed files with 82 additions and 1 deletions
Loading…
Reference in new issue