https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951
--- Comment #17 from Vitali <vlovich at gmail dot com> --- I was explicitly asked to open this as a separate bug in comment #7 of 87950. Would be helpful if the GCC devs could coordinate to figure out if they want separate bugs for C/C++ or 1 bug. Jonathan, on this forum your feedback comes off a bit like Skinner where he blames the children. There's clearly a gap between how compiler authors define switches as working & how developers wish to use those enums/wish those enums were actually defined. I appreciate there's a large amount of legacy code that complicates this issue but I don't think that condescending to people trying to communicate the issue in good faith moves the conversation along. I'd argue that clang strikes a much better balance here in terms of the practical implications of the warning even if it's not perfect. In my mind, warnings are most useful when they optimize for a low rate of false positives. The GCC warnings for enums do not in practice have a low rate of false positives and are clearly tuned to minimize false negatives (i.e. accidentally missing a switch statement that doesn't have all enums covered). At the very least it would be useful to give users the power to turn on a warning equivalent to Clang's that minimizes false negatives (or change -Wswitch to be equivalent to Clang & add a -Wpedantic-switch that's part of -pedantic for the current behaviour). You could even provide annotations that let users annotate enums/switches in an explicit fashion to indicate that they can be constructed with non-label values/aren't expected to be depending on which flag you choose to use to silence warnings/let the compiler optimize more fully. In practice, definitely in C++, enums ARE intended to be a closed set of all possible paths & the flags/random integer value cases are far less frequently used; even for bitmasks it's a lazy way to do it. In C++ I usually define strongly-typed types that represent the bitmask & overload the bit math operators for the enum to yield that secondary type. I think considering that's a technique used by Boost & Qt, it's reasonable to assume that having the enum double as the storage type for the bitmask is more of a hack technically allowed than one that is considered best practice by large C++ projects. In C it's more muddled because there's no operator overloading, but the number of enums that exist far outnumber the uses where it's used for bitwise math.
