[Development] API style guide: scoped enum or not?

[Allan Sandfeld Jensen]

On Mittwoch, 3. Mai 2023 19:40:18 CEST Marc Mutz via Development wrote:
> On 03.05.23 19:22, Thiago Macieira wrote:
> > On Wednesday, 3 May 2023 09:40:42 PDT Giuseppe D'Angelo via Development 
wrote:
> >>   To me it's a no brainer: any new enumeration
> >> 
> >> added to Qt shall be an enum class.
> > 
> > I'd say that any new enumeration in the Qt namespace should be enum class,
> > but enums in classes may not be so if they're sufficiently descriptive
> > already.
> That's the wording we currently have, and I have two problems with that:
> 
> - it's subjective, which means we get to quarrel over every class-scope
> enum anew
> - it completely ignores the point that scoped enums don't implicitly
> convert to underlying_type, which is a very welcome subtraction from
> C/C++'s infamous implicit conversion mess
> 
> So if it's a vote: +1 for all new enums being scoped and +1 for all old
> enums being made scoped come Qt 7.
> 
I am not sure I want the name scope in all cases QEvent::Timer is descriptive 
enough, and would be improved by being QEvent::Type::Timer. With new classes 
in Qt6, I have generally preferred using scoped enums, but found several 
instances were it didn't make sense.  For instance using QColorSpace::SRgb and 
QColorSpace::AdobeRgb for predefined color-spaces, where all other enums in 
QColorSpace are scoped.

Wasn't there a new C++ proposal for decoupling the two separate features of 
enum class?

Best regards
Allan