Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AIP-203 Required field behavior for Wrapper type fields #1415

Open
eddiesoller opened this issue Aug 29, 2024 · 0 comments
Open

AIP-203 Required field behavior for Wrapper type fields #1415

eddiesoller opened this issue Aug 29, 2024 · 0 comments

Comments

@eddiesoller
Copy link

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.

google.protobuf.BoolValue foo = 1 [(google.api.field_behavior) = REQUIRED];

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"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant