Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Thu, 23 May 2024 15:11:45 +0200
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <v2nfai$1ougd$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$1@dont-email.me>
 <9be0c55c-38f8-496c-b335-84ad281e1753@gmail.com>
 <v2nc5h$1oban$1@dont-email.me>
 <c5866b5a-0314-4e70-af56-a86b63986b0c@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 May 2024 15:11:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f9e44f8620308395335310dec31cb554";
	logging-data="1866253"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/c1K6n55oAELoTlqTu3zruLOfnZdoW65w="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:gODOYwQaIOYS4ZFkVPGNEw7dvZE=
Content-Language: en-GB
In-Reply-To: <c5866b5a-0314-4e70-af56-a86b63986b0c@gmail.com>
Bytes: 4649

On 23/05/2024 14:38, Thiago Adams wrote:
> On 23/05/2024 09:17, David Brown wrote:
>> If I try to be precise about the terms "constant expression", "integer 
>> constant expression", etc., I suspect I will get the details wrong 
>> unless I spend a lot of time checking carefully.  So I hope it is good 
>> enough for me to be a bit lazy and quote the error messages from gcc 
>> (with "-std=c23 -Wpedantic").
>>
>>
>> With this code, compilation fails "initialiser element is not a 
>> constant" for y.
>>
>>      int x = 100;
>>      int y = x / 20;
>>      int zs[y];
>>
>>
>> With this code, compilation fails because the zs is actually a VLA, 
>> and "variably modified 'zs' at file scope" is not allowed.
>>
>>      const int x = 100;
>>      const int y = x / 20;
>>      int zs[y];
>>
>>
>> This code, however, is fine:
>>
>>      constexpr int x = 100;
>>      constexpr int y = x / 20;
>>      int zs[y];
>>
>>
>> This also works, even for older standards:
>>
>>      enum { x = 100 };
>>      enum { y = x / 20 };
>>      int zs[y];
>>
>>
>> But constexpr works for other types, not just "int" which is the type 
>> of all enumeration constants.  (And "enum" constants are a somewhat 
>> weird way to get this effect - "constexpr" looks neater.)
>>
>> And in general, I like to be able to say, to the compiler and to 
>> people reading the code, "this thing is really fixed and constant, and 
>> stop compiling if you think I am wrong" rather than just "I promise I 
>> won't change this thing - or if I do, I don't mind the nasal daemons".
> 
> We can write:
> 
> #define X 100
> #define Y ((X) / 20)
> int zs[Y];
> 
> I cannot see a good justification for constexpr.

Clearer code, better checking along the way, better typing.  I don't 
think constexpr lets you do things you couldn't do before, but it lets 
you do those things in a neater way.  (IMHO.)

> I already see bad usages of constexpr in C++ code. It was used in cases 
> where we know for sure that is NOT compile time. This just make review 
> harder "why did someone put this here?" conclusion was it was totally 
> unnecessary and ignored by the compiler. The programmer was trying to 
> add something extra, like "magic" hoping for something that would never 
> happen.
> 

IME poor or confusing uses of "constexpr" are for functions, not 
objects, and C23 does not support "constexpr" for functions.

I think it is better to think of constexpr functions in C++ as "pure" 
functions - confusingly called __attribute__((const)) functions in gcc 
and [[unsequenced] functions in C23.  That is, functions that don't 
affect anything around them, are not affected by anything external, have 
no side effects, always give the same results for the same parameters, 
and can be called more or fewer times without affecting the program's 
observable behaviour.  (It's not exactly like that in C++ - a 
"constexpr" function is implicitly inline and needs a local definition. 
But I think that is how it could have been handled.)

The whole thing - in C and C++ - suffers somewhat from being addons over 
time rather than part of the original design of the language.  But 
that's inevitable as an old language evolves.