[Development] API style guide: scoped enum or not?
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Wed May 3 18:40:42 CEST 2023
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.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230503/00214158/attachment.bin>
More information about the Development
mailing list