[Development] API style guide: scoped enum or not?

[A. Pönitz]

[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 at 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'