-
Notifications
You must be signed in to change notification settings - Fork 185
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
proto3 'optional' keyword support #523
Comments
Any update? |
@zs-dima Do you have the source for that? I'm aware of two design documents related to
As far as I can see none of these say that |
@osa1 I'm also wondering the writing of optional fields. If I want a structure with an optional field to be null, do I just init the structure without assign that field? And if I want to update a field from not null value to null value, how can I do it? |
@osa1 thanks a lot for looking into |
Many thanks but sorry to be here to mention: Foo? get foo => $_getIZ(2);
// ...
foo?.doSomething(); // this conditionally calls the function only if `foo` is not null. which is in place of if (hasFoo) {
foo.doSomething();
} Also, we can benefit from var msg = CameraImageMessage()
..width = rawImage.width
..height = rawImage.height;
msg.planes
..clear()
..addAll(rawImage.planes.map((e) => CameraImageMessage_Plane()
..height = e.height // this errors when setter of field in ⬆️Cam...Plane receives no nullable value.
..width = e.width
..data = e.bytes
..bytesPerPixel = e.bytesPerPixel
..bytesPerRow = e.bytesPerRow)); With property
Thank you. |
To answer my own question and elaborate, the field presence spec clearly specifies that the default value for message fields should be
So yes, we should use nullable return types for getters in fields with message types, and return |
I would also like to have the optional types nullable. So far this is the most anoying thing with this package I came across. It is so easy to make a mistake to not check if the value exist with the |
how have people worked around it? it's super annoying because I have nested objects in a protobuf response and so I have to do a nest hasX check as far as I know |
Hello everyone! 👋 I want to try to add support for nullable types, and I would like to know if it's better :
Thanks a lot in advance ! |
@johynpapin option 1 looks nice to support (temporary) old projects. |
@zs-dima I'd be really happy to discuss this and get some advice, and see if it's possible to break this functionality down into steps. |
@johynpapin Hi there! However I'm sad to say I haven't been on this for a long time, but if possible, I'd like to help out. |
@ryuujo1573 I will start to develop, and if at some point I see a point on which it would be possible to work together, I will contact you. 😄 (But maybe it's not a big enough change to be done by several people initially.) |
Currently
optional Timestamp
andoptional Duration
generate non-nullable types.However proto3 'optional' keyword means nullable types.
Could be nice to fix this issue to be able to have nullable and non-nullable proto3 types processed correctly.
protocolbuffers/protobuf#2168
protocolbuffers/protobuf#8822
Thanks in advance
The text was updated successfully, but these errors were encountered: