mirror of
https://github.com/protocolbuffers/protobuf-go.git
synced 2024-12-26 21:24:22 +00:00
acaef6adb7
The Go generator has historically always prefixed an enum value with the name of the enum type, when it was unnecessary to do so. For example: enum Status { STATUS_FAILED = 0; STATUS_PASSED = 1; } would be generated as: type Status int32 const ( Status_STATUS_FAILED Status = 0 Status_STATUS_PASSED Status = 1 ) It is common for the enum values to be manually prefixed by the enum type since protobuf enums use C++ namespace rules where enum types and enum values are in the same namespace scope. Thus, having the Go generator add a prefix is redundant. See https://github.com/golang/protobuf/issues/513. Some custom Go generators like protoc-gen-gogo allow removing the prefix with the gogoproto.goproto_enum_prefix feature. However, this leads to interoperability issues between protoc-gen-go and protoc-gen-gogo, where the enum value names cannot be accurately inferred. Avoid this problem by just hard-coding the enum value number for values declared in other packages. This provides benefits in interoperability at the small cost of enum values possibly being stale if their value were ever changed in a remote package. However, this would only occur with use of proto2 enums and default values, which seems to be an exceptionally rare situation. Before: Default_MyMessage_MyField = remotepb.FooEnum_FOO_ENUM After: Default_MyMessage_MyField = remotepb.FooEnum(4) // remotepb.FooEnum_FOO_ENUM Before: func (x *MyMessage) GetField() remotepb.FooEnum { ... return remotepb.FooEnum_FOO_ZERO } After: func (x *MyMessage) GetField() remotepb.FooEnum { ... return remotepb.FooEnum(0) // always 0 for proto3 and often 0 for proto2 } Change-Id: I3a06cd553f2eaf6124666f6c36c196d500d35718 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/319649 Trust: Joe Tsai <joetsai@digital-static.net> Reviewed-by: Damien Neil <dneil@google.com> |
||
---|---|---|
.. | ||
internal_gengo | ||
testdata | ||
annotation_test.go | ||
main.go |