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

[Marc Mutz]

On 14.06.23 14:59, Marc Mutz via Development wrote:
> A) new enums MUST have an explicit underlying type¹²

It's actually worse. In the 6.6 header review, several enums add 
enumerators that cross a power-of-two boundary, one even crosses 2⁸.

The C++ standard give compilers a lot of leeway in picking the 
underlying type of an unscoped enum with no explicit underlying type: 
https://eel.is/c++draft/dcl.enum#7

I would propose, therefore, two following, additional rule:

A2) any existing enum that gets extended MUST have a fixed³ underlying type

If it doesn't, then the commit that extends the enum MUST be prefixed by 
two other commits:
1. a commit adding a
        static_assert(std::is_same_v<
                std::underlying_type_t<Enum>,
                ExpectedType>
            );
    in the header file defining `Enum`. This patch MUST be picked into
    the last LTS
2. if (1) has been successfully integrated into dev and the last LTS, a
    commit that reverts the static_assert and fixes the enum's underlying
    type. This patch MUST NOT be picked to an older branch.

After these have landed, the enum can be safely extended.

Rationale: the first patch being in the LTS branch alerts us if any 
tool-chain disagrees with our expected underlying type. If at any later 
time, we get a bug-report saying that the static_assert triggered, we 
know we have to adjust the underlying type. The second patch fixes the 
assumption, forcing the compiler to alert us if a newly-added enumerator 
cannot be represented in the given underlying type.

³ a scoped enum has a fixed underlying type: int

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B