Modules implicate the entire toolchain, backward compatibility, and binary compatibility. constexpr is a compiler feature. Wild that they are being compared.

Indeed, however there is a certain velocity how many years after the standard gets ratified until the compilers get fully compliant.

Since C++14 that I have increasingly changed my mind that it should only be about existing practice, and no paper should be accepted without implementation, regardless of how basic it may be, just like in other language ecosystems.

Yes it might prevent lots of cool features, yet how good are they if it takes years to be implemented across compilers, or they turn out to be yet another export template.

Additionally it would help to reduce count from those 300+ people, not everyone is there for good reasons, some only want to have a "contributed to C++" on their background, and then they are gone.

Yeah, maybe they should have, would have been a lot simpler.

But C++ really wanted modules to be a more or less drop in replacement for #include (or at least a set of common use cases), which really pushed up the required level of complexity.

Maybe, however always telling what they should have done won't change the languages position on the market, so we get what we can have.

Many things D might have done it first, yet it is hardly acknowledged, or has any impact on adoption without a major backer.

I also keep telling WG14 should care about security, since Usenet days, fighting windmills.

see Herb Sutter’s cppfront / cpp2 for a sane approach to sanity, IMO

    static VARIABLE: Foo = bar(); // May or may not be evaluated at compile time

Under what circumstances would this not be evaluated at compile time? As far as I know the initializer must be const.

Unlike C++, Rust does not have pre-main (or pre-_start) runtime initializers, unless you use something like the ctor crate. And the contents of that static must be already initialized, otherwise reading it (especially via FFI) would produce unknown values.

To evaluate something at runtime you'd have to use a LazyCell (and LazyCell::new() is const), but the LazyCell's construction itself will still be evaluated at compile time.

That Rust constant named CONSTANT, is an actual constant (like an old-school #define) whereas in C++ what you've named CONSTANT is an immutable variable with a constant initial value that the language promises you can refer to from other constant contexts. This is a subtle difference, but it's probably at the heart of how C++ programmers end up needing constfoo, constbar, const_yet_more_stuff because their nomenclature is so screwed up.

The VARIABLE in Rust is an immutable static variable, similar to the thing you named CONSTANT in C++ and likewise it is constant evaluted so it happens at compile time, there is no "may or may not" here because the value is getting baked into the executable.

If we want to promise only that our mutable variable is constant initialized, like the C++ VARIABLE, in Rust we write that as:

    let mut actually_varies = const { bar() }; // Guaranteed to be evaluated at compile time

And finally, yes if we write only:

    let mut just_normal = bar(); // This may or may not be evaluated at compile time

So, I count more possibilities in the Rust, and IMNSHO their naming is clearer.

That's a great point.

Here's the thing - that cannot be fixed. Consider the x87 FPU. It does all computations to 80 bits, regardless of how you set the flags for it. The only way to get it to round to double/float is to write the value out to memory, then read it back in.

Java tried this fix. The result was a catastrophe, because it was terribly slow. They backed out of it.

The problem has since faded away as the X86_64 has XMM registers for float/double math.

C still allows float to be done in double precision.

D evaluates CTFE in the precision specified by the code.

More to the point, constexpr does supply something D doesn't do. Whether D runs a calculation at compile time or run time is 100% up to the programmer. The trigger is a Constant-Expression in the grammar, a keyword is not required.

BTW, D's ImportC C compiler does the same thing - a constant expression in the grammar is always evaluted at compile time! (Whereas other C compilers just issue an error.)

    int sum(int a, int b) { return a + b; }
    _Static_assert(sum(1,2) == 3, "message");  // works in ImportC
    _Static_assert(sum(1,2) == 3, "message");  // gcc error: expression in static assertion is not constant