[Development] Proposing to change https://wiki.qt.io/API_Design_Principles#Enums_in_classes to require scoped enums
Mathias Hasselmann
mathias at taschenorakel.de
Thu Jan 16 16:13:50 CET 2025
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>
More information about the Development
mailing list