[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=81665

--- Comment #18 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Vitali from comment #17)
> 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.

This reminded me of bug 81665