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.m...@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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
