(If you don't use Go protocol buffers, you can stop reading) Hello gophers,
This is an announcement that we will be merging the dev branch of github.com/golang/protobuf <https://github.com/golang/protobuf/tree/dev> into master on April 30th (approximately 3 months from now). This merge will introduce several significant changes: - A new table-driven implementation that is shown to be about 1.3x to 2.1x faster when tested inside Google. - The preservation of unknown fields in proto3 messages <https://github.com/google/protobuf/issues/272>. - Validation that strings are valid UTF-8 as specified in the language guides <https://developers.google.com/protocol-buffers/docs/proto3#scalar>. When tested inside Google, we discovered that these changes were more disruptive than expected. The cause of the issues are mostly due to additional fields added to generated messages by protoc-gen-go: - An XXX_NoUnkeyedLiteral field that the generator now creates to force users to use keyed literals (e.g., foopb.Message{Name: "Golang", Age: 8} as opposed to foopb.Message{"Golang", 8}) to ensure forward compatible usage of messages. - An XXX_unrecognized field that is necessary for proto3 to always preserve unknown fields. This breaks users that assume comparability of proto3 messages. Since XXX_unrecognized is of type []byte, this means that proto3 messages cannot be used as map keys nor directly compared using the == operator. - An XXX_sizecache field that is part of the internal implementation of the table-driven serializer. The presence of this field can break tests that use reflect.DeepEqual to compare some received messages with some golden message. It is recommended that proto.Equal be used instead for this situation. The semantic changes may also cause issues: - Strict validation of string fields as valid UTF-8. It is regrettable that the Go implementation has not enforced the encoding thus far, and that was an oversight on our part. However, in order for protobuf messages to be properly parsed by implementations in other languages, it is important to produce an error on the Go side to protect users from generating invalid messages. If your strings do not use UTF-8, then consider using the bytes type. - Preservation of unknown fields in proto3. In nearly all use-cases, this change should not cause an issue. However, the preservation of unknown fields can cause issues if you relied upon proto3 to drop unknown fields (e.g., for security reasons to avoid leaking sensitive information). Note that the proto3 specification has previously said such behavior is unspecified. To explicitly drop unknown fields, users should use proto.DiscardUnknown <https://godoc.org/github.com/golang/protobuf/proto#DiscardUnknown> as appropriate. Note that the Go Protocol Buffer compatibility agreement <https://github.com/golang/protobuf#compatibility> reserves the right to make changes to internal XXX fields or due to specification errors without violating backwards compatibility. We are still making an announcement in advanced so that appropriate user-side changes can be made beforehand so that the eventual merge causes as little disruption as possible. We recommend that you try vendoring the the dev branch to check whether your code works properly with the upcoming Go protobuf changes. If you experience failures, we recommend that you perform the appropriate fix as mentioned in the points above. If you discover any issues with the dev branch, feel free to file an issue on the golang/protobuf tracker <https://github.com/golang/protobuf/issues>. Thanks, JT (on behalf of the Go library team) P.S. Note that this only affects golang/protobuf <https://github.com/golang/protobuf> and not gogo/protobuf <https://github.com/gogo/protobuf>, which is a fork of the former. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
