-
Notifications
You must be signed in to change notification settings - Fork 15.5k
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
Consider removing HasFoo/ClearFoo() for proto2 message fields in C# #7395
Comments
Note that we can also remove the Has/Clear for oneof fields, given that users can use the existing |
The case for removing it from oneof fields is still fairly compelling though:
|
Looks like that's not the case. It also looks like this is an expected inconsistency when upgrading from proto2 to proto3 in other languages, so I'll leave it in C# too. |
This is a breaking change in terms of proto2 code generation: users who were previously using these members will have to change to null checks for message fields. After toying with removing Has/Clear for proto2 oneof fields, I've left them alone in this commit, for consistency with other languages. The inconsistency between proto2 and proto3 won't come up here, because proto3 oneof fields can never be explicitly optional. Fixes protocolbuffers#7395.
This is a breaking change in terms of proto2 code generation: users who were previously using these members will have to change to null checks for message fields. After toying with removing Has/Clear for proto2 oneof fields, I've left them alone in this commit, for consistency with other languages. The inconsistency between proto2 and proto3 won't come up here, because proto3 oneof fields can never be explicitly optional. Fixes protocolbuffers#7395.
To clarify that title, by "proto2 message fields" I mean "fields in a proto2-syntax message, where the type of the field is a message type".
This code:
is just equivalent to:
or (more modern idiom)
Likewise
person.ClearAddress()
is just equivalent toperson.Address = null;
We should consider removing the presence accessors here.
Note that this becomes trivial to do after #7382 is merged.
The text was updated successfully, but these errors were encountered: