[Development] Naming convention for (scoped) enums

[Eike Ziller]

> On 14. Aug 2018, at 12:30, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:
> 
>> 
>> On 14 Aug 2018, at 12:13, Alex Blasche <alexander.blasche at qt.io> wrote:
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Tor Arne Vestbø
>>> That circular logic 😊 Or at least arguing that we should maintain the policy not
>>> because it makes sense, but just because we’ve done so in the past.
>>> 
>>> You are not questioning _why_ we have done so in the past (for decades as you
>>> say), which should be the input to whether or not we want to maintain the policy
>>> as is, or update it to match the current landscape of Qt and C++.
>>> 
>>> The mere fact that we’ve had a policy does not have any value.
>> 
>> Well, so far you only questioned the scoped enum case and making an argument for the scoped enum case based on so far accepted rules  for unscoped ones is valid.
> 
> So let’s explicitly make this a discussion about the whole policy then, since it seems that wasn’t obvious 😊 
> 
>> 
>> 
>>>> Therefore QQuickEventPoint::State::Pressed is no more verbose than
>>> QQuickEventPoint::PressedState.
>>> 
>>> Again, the policy does not mandate that in it’s current form in my reading of it,
>>> and even if it did, that would be a bad policy and we should fix it, not just blindly
>>> accept it as set in stone, because we’ve followed it "for decades".
>> 
>> To quote the policy:
>> 
>> "By comparison the following example illustrates the dangers of missing type safety and giving general names to conventional enum values:"
>> ...
>> " One guideline for naming enum types is to repeat at least one element of the enum type name in each of the enum values"
>> 
>> I think the policy is explicit.
> 
> The policy uses a global enum as an example. Obviously we need some sort of scoping there, either in the enum value names, or by using scoped enums. We agree there, and can leave that part of the discussion as solved.
> 
> The discussion here is about what to do when the enum lives inside a class, which would already solve the naming clash issue in most cases.
> 
>> Whether you think it is bad is a different kind of thing. Please don't mix that.
> 
> That’s kind of the point of bringing up a policy on the mailing list, to argue that it’s bad, and we should change it…
> 
>> Personally, I think this naming rule has served us well and although it is not consistently applied the majority of enums does follow them. 
>> 
>>>> In summary, there is very little verbosity added even by existing rules. Mind
>>> you, Qt has always favoured readability and accepted verbosity as a
>>> consequence in times of code completion.
>>> 
>>> Code completion (for those that use it), only helps with writing code, and as we
>>> all know, most time is spent reading code 😊
>>> 
>>>> 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, 

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
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?

> 
> You conveniently left out this part of my reply:
> 
>>> Clang warns about this with -Wenum-compare for both unstopped and scoped enums, we could easily make that and error and have the best of both.
> 
> 
> Cheers,
> Tor Arne 
> 
>> 
>> --
>> Alex
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
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