4 ms·
That decision seems practical (especially at Google scale). I think the main problem with it, is that you cannot distinguish if the field has the default value
by fisian 2y ago
That decision seems practical (especially at Google scale).
I think the main problem with it, is that you cannot distinguish if the field has the default value or just wasn't set (which is just error prone).
However, there are solutions to this, that add very little overhead to the code and to message size (see e.g. [1]).
[1]: https://protobuf.dev/programming-guides/dos-donts/ https://protobuf.dev/programming-guides/dos-donts/
- sebastos 2y agoThe choice to make 'unset' indistinguishable from 'default value' is such an absurdly boneheaded decision, and it boggles my mind that real software engineers allowed proto3 to go out that way. I don't get what part of your link I'm supposed to be looking at as a solution to that issue? I wasn't aware of a good solution except to have careful application logic looking for sentinel values? (which is garbage)
- jsnell 2y agoYes, proto3 as released was garbage, but they later made it possible to get most proto2 behaviors via configuration. Re: your question, for proto3 an field that's declared as "optional" will allow distinguishing between set to default vs. not set, while non-"optional" fields don't.
- UnluckySelf 2y agoBut you can distinguish between default and unset: all optional fields have has_ method associated with them: https://protobuf.dev/reference/cpp/cpp-generated/#fields https://protobuf.dev/reference/cpp/cpp-generated/#fields