[Development] Naming convention for (scoped) enums

[Eike Ziller]

> On 14. Aug 2018, at 13:18, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:
> 
> 
>> On 14 Aug 2018, at 13:13, Eike Ziller <Eike.Ziller at qt.io> wrote:
>> 
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the problems that were the driver for creating strongly typed enums:
>> 
>> 1. Implicit conversion to integer
>> 2. Inability to specify underlying type
> 
> https://en.cppreference.com/w/cpp/language/enum describes types for unscoped enums too, curious, what’s the difference for the scoped enums?
> 
>> 3. Scoping
>> 
>>> that specifically mentions the enum inside a class use case a primary driver?
>> 
>> Why would the implicit conversion problem be any different for enums inside a class?
> 
> It wouldn’t. I was referring to the scoping/name clash, which is what this discussion has been largely focusing on (so far).

Now you cut off context. I was answering to:

>>>> 
>>>> There is one more very important aspect. Scoped enums can have dedicated
>>> types and are type safe. This could have easily caught issues like (which
>>> coincidently was pointed out to me this morning):
>>>> 
>>>> https://codereview.qt-project.org/#/c/236736/
>>>> 
>>>> And I believe that is a very good reason to still prefer scoped enums.
>>> 
>>> How frequent is this class of bugs?
>> 
>> Frequent enough for it being the primary driver behind the introduction of scoped enums?!?
> 
> Do you have a source for this, that specifically mentions the enum inside a class use case a primary driver?

Which is about type-safety, not scoping.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B