Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Sat, 19 Oct 2024 19:49:58 -0300
Organization: A noiseless patient Spider
Lines: 120
Message-ID: <vf1d2o$2hjk$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 20 Oct 2024 00:50:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="26ddf3a2db6c9a64a775b4526ef6ea85";
	logging-data="83572"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+XyzYtX2GQXFlNH1ARkK2R/0jtZkBJdyQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2I/MKWAMl3yp5xH6TKEdZ6YHQO0=
Content-Language: en-GB
In-Reply-To: <87y12jpxvl.fsf@nosuchdomain.example.com>
Bytes: 5409

Em 10/19/2024 6:48 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> Em 10/19/2024 1:03 PM, David Brown escreveu:
>>> On 19/10/2024 17:18, Thiago Adams wrote:
>>>> Em 10/18/2024 8:54 PM, Keith Thompson escreveu:
>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>> I think constexpr keyword is unnecessary.
>>>>>
>>>>> Sure, most language features are strictly unnecessary.
>>>>>
>>>>>> Anything you do with it could/should be done with const.
>>>>>
>>>>> No, absolutely not.
>>>>>
>>>>
>>>> If not, do you have a sample where, using "const" as "constexpr",
>>>> would create problems?
>>>>
>>>> The sample I know is VLA.
>>>>
>>>> const int c = 2;
>>>> int a[c]; //a is VLA because c is not a constant expression.
>>>>
>>>>
>>>> But this is not enough to convince me because it is better not to
>>>> be a VLA here.
>>>>
>>> What practical difference would it make?
>>
>> I don't see any practical difference. In theory, the generated code
>> could be different, but I'm arguing that this doesn't really matter
>> and, consequently, it's not a good reason to differentiate between
>> const and constexpr.
> 
> My reasons for not wanting `const int c = 2;` to make c a constant
> expression have nothing to do with any theoretical difference in
> generated code.
> 
> My reason is that "const" and "constant" are two almost entirely
> distinct concepts.  Conflating them makes the language more confusing.
> Making the name of a "const" object a constant expression adds no new
> capabilities beyone what we already have with "constexpr".

I see some differences but not enough to justify a new keyword and I 
think it also generates confusion. So it is a matter of choosing what 
that of confusion we want.

For instance, in file scope,

const int a = 1;
constexpr int b =1;

In both cases, because it is file scope, a and b need to be initialized 
with constant expressions. I don´t see anything more special in b 
compared with a to make any distinction.



> 
> Though the C23 standard hasn't yet been officially released, it's too
> late to make any substantive changes.  C23 *will* have constexpr, and
> *will not* treat const-qualified objects as constants.
> 

clang is already doing that (Allowing constant variable be used in 
compile time). But It may be removed it in the future.
and I understand constexpr is already inside the C23.

> If I want a name for a constant expression of type int, I can (in C23)
> use "constexpr", which clearly expresses that intent.  Using "const"
> instead, in all versions of C up to and including C23, will result in
> compile-time errors.
> 
> Let's pretend that when "const" was introduced in C89, it was spelled
> "readonly", which more closely reflects its meaning.  Would you suggest
> that
> 
>      readonly int n = 42;
> 
> should make n a constant expression?
> 
> What you propose would make n a constant expression if and only if its
> initializer is constant. 

Yes, one of my points is that compilers will have to check whether the 
initializer is a constant expression anyway. constexpr isn’t helping the 
compiler or telling it something it doesn’t already know. It’s just 
telling the compiler to do something it likely would do anyway, even for 
local variables. So, the absence of constexpr is essentially telling the 
compiler to ignore something it already knows and preventing existing 
code from being handled at compile time

Consider:

const int c = 2;
int a = 0;
a = 1/(c-2);


The division by zero (c-2) will not be handled at compile time. Changing to:

constexpr int c = 2;
int a = 0;
a = 1/(c-2);

it will catch this even without flow analysis.

So, again, I don´t see a reason for not doing the same analysis using 
const or allowing const variables be used in constant expressions.


>In C23, n is a constant expression if and only
> if n is defined with "constexpr".  If you add "constexpr" to a
> declaration whose initializer is not a constant expression, it will be
> rejected.

It seems like an artificial limitation has been introduced instead of 
generalizing const.