[Development] Proposing to change https://wiki.qt.io/API_Design_Principles#Enums_in_classes to require scoped enums

[Mathias Hasselmann]

Am 16.01.25 um 11:56 schrieb Marc Mutz via Development:
> Hi,
>
> Groundhog Day...
>
> Like every API review, so also in 6.9, we have the discussions between
> proponents of scoped vs. unscoped enums in class scope.
>
> Can we, please, settle this by strengthening the wording of
> https://wiki.qt.io/API_Design_Principles#Enums_in_classes to something
> that requires scoped enums?
>
> I believe everyone agrees that there are _technical_ reasons to prefer
> scoped enums: no implicit conversion to underlying_type, defined
> underlying type even if not explicitly given, etc.
>
> Which leaves the stylistic issue. But I believe the argument
Which is an important one: Unless your code is entirely irrelevant it 
should have much more readers than writers. Style is important.
>   > Using scoped enums in this case would add redundant line noise:
>
> is a very _un_-Qt-ish one. In Qt, we believe that brevity does not
> automatically equal readability¹, and the more explicit
>
>   > if (point.state() == TouchPoint::State::Pressed)
>
> is more (but certainly not less) readable than
>
>   > if (state() == TouchPoint::Pressed)

You don't win an argument by picking the most appropriate example 
supporting your case, and ignoring the next given just a few lines 
below: All these enumerations in the QRegularExpression class.

Do you really propose that we write 
QRegularExpression::PatternOption::UseUnicodePropertiesOption in the 
future? That's an identifier of 61 characters length. Considering my 
thoughts about such identifiers is left exercise to the reader.

My proposal would be, to wait with making scoped enums mandatory until 
Qt requires C++ 20. With C++ 20 we will get "using enum", which brings 
us the best of both world: The much better typesafety of scoped enums 
and the option to have brief identifiers for tightly coupled, nested 
enumerations.

Ciao
Mathias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20250116/2c4831d4/attachment.htm>