The syntax 3 of protobuf made all the fields optional dropping the keywords required
and optional
from previous proto2 syntax. Reading some comments from developers it seems that it was done for enhancing forward/backward binary compatibility.
But for me, that could be enforced by just versioning the package names, say com.example.messages.v1
and then let clients to implement deserializers they understand. At the same time it removes some contracts stated as a type that are useful from a software engineering point of view. For instance if I have
message Location {
double latitude = 1;
double longitude = 2;
}
In proto3 it is possible to create a half backed but perfectly valid Location
by not providing one of the required fields.
Isn't that a big drawback when creating a schema based serialization format for exchanging data between clients? Isn't worse to move extra validation code to each client checking that all required fields have valid values?
Best Answer
proto3 makes a number of changes aimed (as I understand it) at making it far more usable in cross-platform scenarios. Explicit tracking of "assigned" vs "not assigned but reporting the default value" can be very hard to implement on some of the target platforms, and can also be confusing to use. As such, proto3 adopts a much simpler approach:
The other value is: zero. The fact that you didn't explicitly assign it to zero is moot. Whether or not this is desirable is up to you, but it makes sense to me and is how a lot of "initialize a new object / struct" works on a wide range of platforms.
There's nothing to validate! The layout is exactly what it would be if the value zero was explicitly assigned. If that is legal, it is legal. If it is illegal (because zero doesn't make sense to you), it is illegal; but it would be illegal whether it was explicit or implicit. The amount of validation involved doesn't change.
Not usually, no... especially since the schema version is explicit. If you want to use proto2: use proto2. Nothing changes automatically.