C++11 enum class

[denisiussion]

It would be great use 'enum class' in the C++11 code generation.

[hadrielk]

yes it would be awesome, but it sounds like it would be surprisingly hard to achieve: see #1079

[xfxyjwf]

@hadrielk It depends on what's your goal. If you want to allow such proto definition:

// proto file
enum Foo {
  UNKNOWN = 0;
}
enum Bar {
  UNKNOWN = 0;
}

this is not possible even with C++11 enum class, because protobuf internally flattens the name scope and the two UNKNOWN enum values conflict with each other.

However, if you just want to make protoc generate C++11 enum classes, that should be pretty easy after C++11 is required to build protobuf.

[hadrielk]

So I guess the advantage with that latter case is you'd get to avoid implicit type conversion when it's used in the generated accessor functions? That's good sure. But yeah for me the goal is to use the same enumerator names in different enums in the same namespace/package. 😢

[hadrielk]

Out of curiosity, is it "flattened" in the sense that the reflection/descriptor stuff can't deal with it being scoped, or do you just mean in the outputted .h/.cc files it's flattened (e.g., in the const variables created for each enumerator name and such)

[xfxyjwf]

It's the former. When we store enum values internally in descriptors, the names we use in indices are flattened (i.e., both Foo.UNKNOWN and Bar.UNKNOWN are indexed by the name "UNKNOWN"), and this is exposed in public APIs such as FileDescriptor::FindEnumValueByName():
https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.h#L1327

If we are to allow two enums to define the same enum value name, all such FindEnumValueByName() APIs will be broken and it will have unpleasant consequences.

It's probably possible to deprecate all such FindEnumValueByName() methods (and all similar enum value name related APIs in every protobuf implementation) and change the behavior after all usage is gone, but that will take time and work. It's hardly worthwhile, I would say.