[re-ordered] On Wed, May 03, 2023 at 05:32:46PM +0000, Axel Spoerl via Development wrote: > > On 3 May 2023, at 18:42, Giuseppe D'Angelo via Development > > <development@qt-project.org> wrote: > > > > 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 > [...] > > +1 for every new enum added being an enum class. Exceptions to be > approved here case by case.
My main problem with enum classes _in Qt_ is that it is inconsistent with what has been there traditionally. It is simply no fun to guess what "style" some enum is (and sure, Peppe has a point when hinting that the naming scheme wasn't applied uniformly in the pre-past either...) I know uniform API isn't exactly en vogue anymore, but in this particular case here I wonder whether it would be possible with reasonable effort to go all-in on enum classes by offering "equivalent" enum classes to non-class enums and e.g. suitable overloads in core API so that I would have "one way to do it" again. Opinions? Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development