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.

    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.