Consider whether the protobuf optional feature is required
The optional feature is only available in newer protoc releases, only the latest Linux distribution can install them via the package manager. This is a little bit inconvenient since some developers may use an old Linux distribution, or already have protoc installed in their environment. We need to consider whether current dependencies on the optional feature are necessary.
from prost's documentation https://docs.rs/prost/latest/prost/#field-modifiers:
Note that in proto3 the default representation for all user-defined message types is Option<T>, and for scalar types just T (during decoding, a missing value is populated by T::default()). If you need a witness of the presence of a scalar type T, use the optional modifier to enforce an Option<T> representation in the generated Rust struct.
If I understand correct, We have to add this optional modifier to force an Option<T>'s default value to be None rather than Some(T::default()).
from prost's documentation https://docs.rs/prost/latest/prost/#field-modifiers:
Note that in proto3 the default representation for all user-defined message types is Option, and for scalar types just T (during decoding, a missing value is populated by T::default()). If you need a witness of the presence of a scalar type T, use the optional modifier to enforce an Option representation in the generated Rust struct.
If I understand correct, We have to add this
optionalmodifier to force anOption<T>'s default value to beNonerather thanSome(T::default()).
You are right. The initial intention was to distinguish "absent" from "empty" of string and bytes. There are indeed no strong motivations that we have to use optional. I will remove them.
closed by #756