AIP-203 includes a helpful note about required primitive fields.
Note: In most cases, empty values (such as false for booleans, 0 for integers, or the unspecified value for enums) are indistinguishable from unset values, and therefore setting a required field to a falsy value yields an error. A corollary to this is that a required boolean must be set to true.
It doesn't advise how to workaround the indistinguishability though.
The well known wrapper message types seem to be intended for cases where it is important to distinguish unset from set to default. It may be important to explicitly specify a boolean value, for example. In which case the field could be.
However, the AIP suggests that it would not be valid if the value was explicitly set to false.
The use of REQUIRED indicates that the field must be present (and set to a non-empty value) on the request or resource.
A field should only be described as required if either:
It is a field on a resource that a user provides somewhere as input. In this case, the resource is only valid if a "truthy" value is stored.
...
We define the term "truthy" above as follows:
For primitives, values other than 0, 0.0, empty string/bytes, and false
For repeated fields maps, values with at least one entry
For messages, any message with at least one "truthy" field.
Would it be reasonable to consider any message field that is set (even to default value) to be considered "truthy"?
AIP-203 includes a helpful note about required primitive fields.
It doesn't advise how to workaround the indistinguishability though.
The well known wrapper message types seem to be intended for cases where it is important to distinguish unset from set to default. It may be important to explicitly specify a boolean value, for example. In which case the field could be.
However, the AIP suggests that it would not be valid if the value was explicitly set to false.
Would it be reasonable to consider any message field that is set (even to default value) to be considered "truthy"?