Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Mon, 28 Oct 2024 06:13:21 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <20241027220459.109@kylheku.com>
References: <veb5fi$3ll7j$1@dont-email.me>
 <877ca5q84u.fsf@nosuchdomain.example.com> <vf0ijd$3u54q$1@dont-email.me>
 <vf0l98$3un4n$1@dont-email.me> <vf1216$p0c$1@dont-email.me>
 <87y12jpxvl.fsf@nosuchdomain.example.com> <vf1d2o$2hjk$1@dont-email.me>
 <87plnvpgb9.fsf@nosuchdomain.example.com> <vf2sm8$deou$1@dont-email.me>
 <vf7m4s$1d8mj$1@raubtier-asyl.eternal-september.org>
 <vf86uc$1fvt3$1@dont-email.me> <vfit29$3obkb$1@dont-email.me>
 <vfj5up$3q2lf$1@dont-email.me>
Injection-Date: Mon, 28 Oct 2024 07:13:22 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fc4472717a3f230580c4c0a6b9110008";
	logging-data="928002"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18/8vjXXJBYbanjGxR/jdfT2mDUrl4ZGT4="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:/6wWF7+hCYgtPdlTQUi/A9kDI08=
Bytes: 3014

On 2024-10-26, James Kuyper <jameskuyper@alumni.caltech.edu> 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.

I also follow that and it's been that way pretty much everywhere
I have worked, at least recently.

But not literally like that.

Of course, you control which warnings are in effect, and fix those.

You disable silly warnings you disagree with, rather than fix them.

The business of deciding what diagnostics are going to be used and which
are not is a separate activity. Usually most of the activity in this are
occurs when there is a compiler change, such as an upgrade.

The newer or different compiler offser some diagnostics which trigger in
the code, and for each, the squelch-or-fix decision has to be made.

It's not always an easy decision, because the value, or lack thereof, of
a diagnostic is not always apaprent from one situation in which it goes
off. Some diagnostics can be wortwhile in spite of a significant false
positive rate.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca