Why are non-scalar fields defaulted to Option<T> ?

[floris-d2x]

Hi, 👋

I have a proto3 message Foo with a field 'x' of type Bar, with Bar being another message.
In rust this maps to a struct Foo with a field 'x' of type Option<Bar>.

Why is this the case? if I want an option could I not just specify the optional modifier?

[LucioFranco]

This is due to the way that proto3 supports message fields as being optional. Its possible for a field to not be included due to backwards compat. https://github.com/tokio-rs/prost#field-modifiers

[floris-d2x]

This is an answer but not the explanation I was looking for; which I found here protocolbuffers/protobuf#2497 (comment) .
I understand now that this is a proto3 thing and not something weird that prost does. Thank you.

[wackazong]

But then again, why are scalars represented as T and not as Option<T>?

[floris-d2x]

https://github.com/protocolbuffers/protobuf/blob/main/docs/field_presence.md

Scalars without the optional tag (and therefor singular) fall under the "no presence" discipline; with the tag under "explicit presence".

If the message you try to deserialize does not contain the field ("no presence"), prost (should) set it to the default value; In case of an i32 this would be 0.

This is what I understand from it, I am not 100% sure about these:

• If you try to serialize an i32 of value 0, it will be absent in the bytestream.
• if you try to serialize an Option<i32> of value Some(0), the value will be in the bytes
• if you try to serialize an Option<i32> of value None, it will be absent.

[wackazong]

Ok, I see. Thanks.