Open justoneplanet opened 8 years ago
It is designed to be this way.
According to: https://github.com/apple/swift-protobuf/blob/master/Documentation/GENERATED_CODE.md
The original implementation of Swift Protobuf generated properties with Swift optional type, but that obvious approach proved problematic. In practice, testing whether a field is set is fairly uncommon and using Swift optionals directly tended to lead to abuse of the Swift ! operator in many cases where the user knew that certain fields would always be set. Instead we generate fields that use Swift optionals internally (to track whether the field was set on the message) but expose a non-optional value for the field and a separate hasXyz property that can be used to test whether the field was set:
That is a silly reason to not use Swift optionals. Most of my protobuf messages contain optionals, and I'm now forced to write code that is more unsafe like so:
// The user now needs to know which messages to make this check for, since only some messages are optional.
if message.hasSubMessage && message.subMessage.hasValue {
return message.subMessage.value
}
Versus using optional chaining:
return message.subMessage?.value ?? false
The point of optionals is to force the user to handle the potential nil case. If they choose to ignore it with the !
operator, that shouldn't be a concern of this library to fix.
Hi, Thanks for the nice plugin!! I found the differences in my generated files.
Version of protoc (
protoc --version
)libprotoc 2.6.1
Version of ProtocolBuffers.framework
2.4.1
.proto
file to reproduceDescription
In (official) Java, request field is set the default value. It is not null.
On the other hand, it is not set in protobuf-swift.
In this case, optional string field is set empty string value.
This is incomprehensible for me. This is a spec or bug?