Re: constexpr keyword is unnecessary

Em 10/20/2024 1:08 AM, Keith Thompson escreveu:

Thiago Adams <thiago.adams@gmail.com> writes:

Em 10/19/2024 6:48 PM, Keith Thompson escreveu:

[...]

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.

 But the new keyword already exists, and will be part of the language for
years.  Removing the constexpr keyword will not be possible, because
doing so would break existing code.

Yes. But const can be improved and we can just ignore constexpr.
Just to show one extra difference from constexpr
we have an error here
//'constexpr' initializer not representable in type of object
constexpr unsigned char c= 1234;
with const it is a warning. But again I don't think is is enough to justify constexpr.

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.

 As of C23, you're right.  But what if a future C standard allows
non-constant initializers for file-scope object (as C++ already does)?
 

Then it could have initialization order problem..and C does not have exceptions to report error in initialization..
What C could have is compile time functions.
const int i = f();
I think this situation can be automatic, the compiler will try to evaluate f at compile time because there is no other alternative.