Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Tue, 29 Oct 2024 19:27:28 +0100
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <vfr9eg$1lokm$1@dont-email.me>
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> <20241027220459.109@kylheku.com>
 <vfnu92$vp1g$1@dont-email.me> <20241028215919.996@kylheku.com>
 <vfqjnk$1hos6$1@dont-email.me> <vfqjvn$1hos6$2@dont-email.me>
 <vfqqhs$1j1i2$1@dont-email.me> <vfqsgm$1ji6h$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 19:27:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="008e3dea2d25a2a1d4afdd318ef41b21";
	logging-data="1761942"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19BHRzVQtemXnh7rxPhofFZENk4lKbSi58="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VykIdLpckbVZpLHaAGuOEA2tDsQ=
In-Reply-To: <vfqsgm$1ji6h$1@dont-email.me>
Content-Language: en-GB
Bytes: 5027

On 29/10/2024 15:46, Thiago Adams wrote:
> On 29/10/2024 11:13, David Brown wrote:
>> On 29/10/2024 13:21, Thiago Adams wrote:
>>> On 29/10/2024 09:16, Thiago Adams wrote:
>>>
>>> Edit to fix the sample
>>>
>>> // Here we acknowledge the truncation
>>> void f(int i) {
>>>      ...
>>>      const unsigned char c = i; [[!truncation]];
>>> }
>>>
>>>
>>> // Warning: there is no truncation to acknowledge.
>>> void f(unsigned char i) {
>>>      ...
>>>      const unsigned char c = i; [[!truncation]];
>>> }
>>>
>>
>> This should give you what you are asking for, if I have understood you 
>> correctly:
>>
>> #define truncate(type, value) \
>>      _Generic((value), \
>>          type : (void) 0, \
>>          default : (type) value \
>>      )
>>
>>
>>
>> // OK
>> void f1(int i) {
>>      const auto c = truncate(unsigned char, i);
>> }
>>
>> // Error
>> void f1(unsigned char i) {
>>      const auto c = truncate(unsigned char, i);
>> }
>>
>>
>> I am not at all convinced this is a good idea.  I am /certainly/ not 
>> convinced "truncate" is a good name - the general term, AFAIK, for a 
>> conversion that might try to squeeze a large value into a smaller type 
>> is "narrowing" rather than "truncating".
>>
>> You could expand the idea further and have a "truncate" macro that 
>> checks for bounds at run time or compile time (I'd make use of the gcc 
>> extension __builtin_constant_p here, but there may be a fully standard 
>> way to do this).
>>
>>
> 
> As I said,
> 
>  >(I intend to show a general idea. There are likely better examples.)
> 
> My objective was to show the concept of "warning acknowledge".
> 
> Name and syntax weren't important.
> 
> The solution for truncate you are proposing maybe is valid, but it is 
> for the specific case.
> I think it is valid to think is specific cases and I can find more samples.
> maybe if (condition) where the condition is constant expressions.
> 

Well, there is already a syntax standardised for use for this kind of 
thing - attributes.  For example, marking a function declaration with 
[[noreturn]] will turn off any warnings about the function failing to 
return.  Attributes are specifically for such additional information to 
improve the compiler's knowledge (for the purposes of optimisation 
and/or static error checking) without affecting the semantics of the code.

(I don't think there is a need for an attribute to disable a narrowing 
initialisation, since a cast will do the job just fine, and I don't see 
any need for a "warn about unnecessary cast" attribute.  But attributes 
could be used for a similar general idea.)

What would have been nice, perhaps, is if C had adopted the C++ 
semantics that "type x = { y };" is an error if it requires a narrowing 
conversion, rather than leaving it up to the compiler to choose to have 
a warning or not.  But I think that would mean a similar unfortunate mix 
of concepts to Keith's complaint about "const" in C++ - such an 
initialisation will be a compile-time error in C++ if "y" is out of 
range and is a constant expression, but not if it is not a constant 
expression.  (You do get a compile-time error in both languages if 
narrowing changes the value for initialising a constexpr variable.)