| commit | f6d4a4215f1097f990051d321c357cd79e02ea27 | [log] [tgz] |
|---|---|---|
| author | Joe Tsai <joetsai@digital-static.net> | Mon Nov 19 14:26:06 2018 -0800 |
| committer | Joe Tsai <thebrokentoaster@gmail.com> | Tue Nov 27 19:13:59 2018 +0000 |
| tree | 6972c59334cfc312f44e356a02c83a239caca02b | |
| parent | 492a476312755200fbec6fb289efcfa9918d228b [diff] |
reflect/protoreflect: clarify Get semantics on unpopulated fields Clearly specify that Get on an unpopulated field: * returns the default value for scalars * returns a mutable (but empty) List for repeated fields * returns a mutable (but empty) Map for map fields * returns an invalid value for message fields The difference in semantics between List+Maps and Messages is because protobuf semantics provide no distinction between an unpopulated and empty list or map. On the other hand, there is a semantic difference between an unpopulated message and an empty message. Default values for scalars is trivial to implement with FieldDescriptor.Default. A mutable, but empty List and Map is easy to implement for known fields since known fields are generated as a slice or map field in a struct. Since struct fields are addressable, the implementation can just return a reference to the slice or map. Repeated, extension fields are a little more tricky since extension fields are implemented under the hood as a map[FieldNumber]Extension. Rather than allocating an empty list in KnownFields.Get upon first retrieval (which presents a race), delegate the work to ExtensionFieldTypes.Register, which must occur before any Get operation. Register is not a concurrent-safe operation, so that is an excellent time to initilize empty lists. The implementation of extensions will need to be careful that Clear on a repeated field simply truncates it zero instead of deleting the object. For unpopulated messages, we return an invalid value, instead of the prior behavior of returning a typed nil-pointer to the Go type for the message. The approach is problematic because it assumes that 1) all messages are always implemented on a pointer reciever 2) a typed nil-pointer is an appropriate "read-only, but empty" message These assumptions are not true of all message types (e.g., dynamic messages). Change-Id: Ie96e6744c890308d9de738b6cf01d3b19e7e7c6a Reviewed-on: https://go-review.googlesource.com/c/150319 Reviewed-by: Damien Neil <dneil@google.com>
WARNING: This repository is in active development. There are no guarantees about API stability. Breaking changes will occur until a stable release is made and announced.
This repository is for the development of the next major Go implementation of protocol buffers. This library makes breaking API changes relative to the existing Go protobuf library. Of particular note, this API aims to make protobuf reflection a first-class feature of the API and implements the protobuf ecosystem in terms of reflection.
List of relevant design documents:
We appreciate community contributions. See CONTRIBUTING.md.
Issues regarding the new API can be filed at github.com/golang/protobuf. Please use a APIv2: prefix in the title to make it clear that the issue is regarding the new API work.