+1 for every new enum added being an enum class. Exceptions to be approved here case by case.
> On 3 May 2023, at 18:42, Giuseppe D'Angelo via Development > <development@qt-project.org> wrote: > > Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto: >> During the header review, but also in API discussions leading up to it, we >> had a few cases where it would have helped if we had clearer guidelines >> about when to use scoped enums, and when not. >> Scoped enums have some clear technical advantages (such as better type >> safety, thanks to no implicit conversion to int). And they sometimes result >> in better APIs when enum values don’t have to repeat the enum’s name in >> order to be clear. > > Should we vote on this? To me it's a no brainer: any new enumeration added to > Qt shall be an enum class. > >> But sometimes it’s also creating too much verbosity to use a scoped enum >> (ie. Qt::Orientation::Horizontal would perhaps not be an improvement). > > I wouldn't consider this tiny bit of extra verbosity a huge impediment. Note > that Qt::Horizontal is violating the API naming guidelines. It should've been > called Qt::HorizontalOrientation. How is that now better than > Qt::Orientation::Horizontal? > > No, Qt::Horizontal isn't "unambiguous" so it can't be non-qualified. Does it > refer to what? Text alignment? Text direction? Layout direction? (Hint: none > of these.) > > The extra verbosity e.g. in switches can be tamed; one more reason to upgrade > to C++20: > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development