Re: constexpr keyword is unnecessary

On 27/10/2024 05:54, Tim Rentsch wrote:

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
 

On 10/26/24 10:07, Vir Campestris wrote:
>

On 22/10/2024 13:48, Thiago Adams wrote:
>

I think a more generic feature would be to have a standard way of
promoting selected warnings to errors.  This would avoid stacking
features with small differences, such as treating constexpr as a
special case compared to other constant expressions in C.

>
I have in the past had coding standards that require you to fix all
warnings.  After all, sometimes they do matter.

>
I disapprove of that policy.  A conforming implementation is free to
warn about anything, even about your failure to use taboo words as
identifiers.  While that's a deliberately silly example, I've seen a
fair number of warnings that had little or no justification.  [...]

 I expect that when people say "all warnings" they don't really mean
all warning conditions that compilers currently can test for, in
the sense of -Weverything in clang (and they certainly don't mean
any warning condition that is allowed to be tested, since as you
point out that is much too wide a circle to be useful).  But by
saying "all warnings" the most important part of the information is
concealed, because we don't know what warning conditions are meant
to be included in "all warnings."  I would happily agree to fix
"all warnings" if I get to choose which set of warning conditions
is covered.  Conversely, I would never agree to fix "all warnings"
if someone else is doing the choosing and doesn't define what set
of warning conditions is to be tested.

Exactly.
The choice of "all warnings" for a particular project (or subproject) should be an active decision, going along with decisions of which language to use, which version of the standards to use, which extensions to allow, which coding standard to follow, and so on.  These are, obviously, related decisions.