Re: constexpr keyword is unnecessary

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.