You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is in the same spirit as #142 however this time it is a much more significant breaking change
Related to commit 20db367
The generated code has changed so that primitives no longer default to the "appropriate zero", but now are force unwrapped optionals. This behaviour does not play well with other protobuf implementations which do not send values which match the default. It also differs from Google's proto3 specification.
The impact of this change is that when serializing this object in java (with the value 0) and then deserializing it in swift will result in a nil NOT the desired 0. The painful way to get the old behaviour is to change all instances of:
let myVal = proto.userId
to
let myVal = proto.userId ?? 0
I also tried this was a work around without success:
uint64 user_id = 1 [default = 0];
Issue.proto: Explicit default values are not allowed in proto3.
The text was updated successfully, but these errors were encountered:
staticgears
changed the title
https://github.com/alexeyxo/protobuf-swift/issues/142
Default value change contadicts proto3 spec
Jul 31, 2017
Version of protoc (
protoc --version
)3.3.2
Version of ProtocolBuffers.framework
3.0.22
.proto
file to reproduceDescription
This is in the same spirit as #142 however this time it is a much more significant breaking change
Related to commit 20db367
The generated code has changed so that primitives no longer default to the "appropriate zero", but now are force unwrapped optionals. This behaviour does not play well with other protobuf implementations which do not send values which match the default. It also differs from Google's proto3 specification.
Here is the specification for proto3 default values:
https://developers.google.com/protocol-buffers/docs/proto3#default
The impact of this change is that when serializing this object in java (with the value 0) and then deserializing it in swift will result in a nil NOT the desired 0. The painful way to get the old behaviour is to change all instances of:
I also tried this was a work around without success:
The text was updated successfully, but these errors were encountered: