optional's comeback
Closed this issue · 4 comments
seems like proto3 supports optional now: https://github.com/protocolbuffers/protobuf/releases/tag/v3.15.0 :-)
Wow! I guess not being able to test for presence in some languages (I could do it in Perl) started to bug enough people. I found https://github.com/protocolbuffers/protobuf/blob/master/docs/field_presence.md which explains it further.
Interestingly I just hit a related issue with the OCaml generated types: while a string or uint32 field will become a string or int record field in OCaml, a Something field will become a something option on the OCaml side. That seems wrong to me, moreso with this here comeback. Shouldn't they behave like scalar values, in that something should not be an option, and all of its fields be at their default values if not part of the data being decoded?
with proto3, I think you're right, it shoudl contain a something. Alas we should also have a bitfield (like C++ does I think) to know what is present or not, because otherwise serializing objects means serializing the default values too, which can get expensive.
Yes I saw #170 and I agree, other implementations skip defaults on the wire as far as I know, so we should too.
As for the something vs something option unfortunately fixing that inconsistency would be a breaking change, so it would have to be an opt-in feature until version 3.🤔
I think using optional string foo = 42; is exactly where we should insert an option for now, and avoid emitting the field if not present. That's explicit and backward compatible.