Re: constexpr keyword is unnecessary

On 26/10/2024 17:08, James Kuyper wrote:

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.
The purpose of warnings is to tell you that there might be a problem. If
the compiler is certain that there's a problem, it should generate an
error message, not a warning. Therefore, treating warnings as if they
were error messages means that you're not doing your job, as the
developer, to determine whether or not the code is actually problematic.

I disagree with you here.
But there is an extra condition involved - without it, you have a fair point.
The choice of compiler (or linter) warnings needs to be appropriate - it needs to be an active decision based on real requirements that are appropriate for the kind of coding task and development style in question.  If someone things they can use "-Wall -Wextra" and all warnings are bugs in the code (or, worse, all bugs in the code lead to warnings), then they are not going to get a good development procedure by adding "-Werror".  The set of warnings /I/ use for /my/ code are not going to match the set that is appropriate for /your/ code - we will each have things in our code that the other things is unacceptable as a risk of error (now or in future maintenance), compatibility, portability, etc.
The compiler warnings also need to be stable.  It is not enough to say that we have decided that "-Wall -Wnounused-function -Wmaybe-uninitialized" is sufficient for your project and coding standards unless you can make fixed requirements on exact compiler versions.  Otherwise, using different compilers or versions can change the warning set.  (I'm using gcc flags in examples - other compilers have other flags.)
When I enable a warning in my builds, it is matching a policy I want for the way I write my code - it enforces a restriction in what I can write.   For example, I generally use enumerated types for states, and it is not uncommon to have a switch statement for dealing with a particular state variable.  So I have "-Wswitch-enum" to give a warning if I've missed out a possible state.  I make that warning an error.  To me, for my code, it is just as much an error in the code if I have added a new state to the enumeration but forgotten to handle it somewhere, as if I had removed a state from the enumeration but forgotten to remove it from the handlers (that would always be a compile-time error).
Good warnings are essential to development.  They are automated checks and catch mistakes early.  Of course they don't catch all mistakes, but they are part of the process - every tool or development procedure that reduces the chances of an error in the final released product is a good thing.  Static checks are very low cost, automated, and come early in the code-compile-test-release cycle and it is thus much easier and cheaper to handle problems found at this point than if they are found later on.
So a good set of warnings is useful to have.  But warnings from compilers don't stop builds.  If you have a typical build process with a makefile (or similar build system) and a bunch of source files, and run "make -j", you'll get lots of outputs and your warnings might be hard to spot, getting lost in the noise.  Running "make" again won't help - files with no errors will not be recompiled, and it will look like your build is nice and clean with no problems or warnings.  Thus once your project is at a stage in development where you expect to see no or few warnings, "-Werror" is key - then you can't miss the warnings.
Of course there will be situations where you'll have false positives - warnings about something that you know is correct in your code.  You will then have to mark this in your code somehow - it might be a slightly different code construct, a compiler-specific attribute, a pragma to disable the warning at that particular point (or for that whole file).  These are definite actions - you are, in effect, noting that this particular piece of code does not clearly comply with your coding policies or standards, and needs to be marked as unusual.  (If this is happening more than occasionally, then go back to your set of warnings and ask if they match the policies you want - or if your policies are appropriate in the first place.)