A new proposal deletes your enum bitmask boilerplate

A scoped enum is the right type for a set of flags: named values, no implicit conversion to int, its own namespace. The moment you want to combine two flags, though, enum class takes the bitwise operators away, and you write them back yourself. Every project has this block somewhere: operator|, operator&, operator^, operator~, the three compound-assignment forms, and usually a has/holds helper. Eight-ish functions, once per bitmask enum, forever.

P4313 “Bitmask operations for enums” (Iliya Guterman and Anthony Williams, in the 2026-07 mailing) proposes deleting that block. You opt a scoped enum into bitmask behavior with an attribute:

enum class [[std::bitmask_type]] Permission {
    None = 0, Read = 1, Write = 2, Execute = 4,
};

and the language supplies |, &, ^, ~ and their compound assignments, operating directly on the enum. Two design points make it more than a macro: there is no implicit conversion, so a Permission and a Color bitmask never mix even though both are flag sets, and the values keep their enum type through every operation rather than decaying to the underlying integer.

The demo is the code the proposal would let you throw away. It compiles today on GCC 16.1 (the attribute does not exist yet, so the operators are hand-written) and prints the result of combining and testing flags:

read   : true
write  : true
execute: false
value  : 3

This is an R0: freshly proposed, not in any compiler, and it will change as it goes through the committee. But it targets a real and universal papercut, and the design (attribute opt-in, type-preserving, no implicit conversion) is the one library authors have been hand-rolling with concepts and CRTP for years. If it lands, the flag-enum boilerplate becomes one attribute.

Source: P4313R0 “Bitmask operations for enums”, Iliya Guterman and Anthony Williams, 2026-07 mailing.