Protobuf: How to make scalar message field which has a default value be serialized on the wire?

[csmatrix]

As we know, in proto3, if a scalar message field is set to its default value, this field will not be serialized on the wire. This feature may result a high transmission speed, but it also bring me a bug sometimes, when a zero value is valid for me but is omitted. How to change this feature, is there any option?

[seishun]

If a field is missing on the wire, you're supposed to interpret it as if it was set to its default value. That's how all implementations I know work.

[csmatrix]

@seishun thanks a lot for your kindly reply. Imaging such scenario, my proto3 C# client sent a msg to a proto2 C++ server, does what you said also work? As you know, proto2 has a bit to indicate whether a field exists but proto3 has not. In this scenario, can C++ server deserialize the data package correctly?

[seishun]

Not sure what you mean by a "proto2 server". Messages should be serialized and deserialized using the same definitions, and that includes syntax (proto2 or proto3).

[xfxyjwf]

There isn't an option to change this. Though you can use the wrapper types:
https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto#L84

[csmatrix]

@xfxyjwf @seishun
I have tried warpper types and oneof fields. I found these two ways could both make the default value be serialized but wrapper types' serialized bytes had a little difference with C++ serialized bytes while oneof fields' serielized bytes was identical to C++ serialized bytes of the default value.
Thank you for all your helps about this issue.

[csmatrix]

@xfxyjwf
One more question. Is there a probability that Protocol Buffers will support C language in the future?

[acozzette]

@csmatrix We don't have any plans to support a C API in the main project, but there are a handful of third-party C implementations listed here that you could try.

[johnnyshao]

@seishun > If a field is missing on the wire, you're supposed to interpret it as if it was set to its default value. That's how all implementations I know work.

This is not true. There're a lot of applications that need different logic. e.g. a project I'm working with where all values could be optional; the connected IoT device only sends changed values to server where only these changed values are stored. So all values that are not sent over the wire are assumed to be same as old values rather than setting to default values.

The good thing is oneof solves this problem without adding any data to the wire but making .proto files very dirty (every logically optional scalar fields need to be defined as oneof).