Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Sat, 26 Oct 2024 21:54:59 -0700
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <86jzduuov0.fsf@linuxsc.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 27 Oct 2024 05:55:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d3e5dc7bdb0f10980bd7d09bc656fcce";
	logging-data="133242"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19YGsMnT6Blwj/vUBmgZlaEhsxy9DtHLEQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:vyGbVQibeLCzzMKRoihQzXAXVt4=
	sha1:23VVS6u0U5VPCfcJPUa3z6v7KzE=
Bytes: 2979

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.