I like this work and their approach but there is a third risk (in addition to the two they mention) which is the risk of skew in the compile time and runtime interpretation of certain constructs.
Obviously when this happens it's a bug; the real question is "if such a bug occurs (i.e. the semantics of the program is affected by the use of constexpr) will it confuse the developer?"
Lisps (which have always intermixed interpreted and compiled code as long as lisp compilers have existed) have often struggled with this problem even though they have in many ways a simpler problem to address.
And since I'm writing about C++: I really love c++ but I hate the keyword "constexpr" as it's actually "const_statement". the distinction between statements and expressions, and the concomitant problem that expressions aren't first class, is a c-inherited botch on the language IMHO.
That risk has nothing to do with this work. That's an inherent risk with compile time evaluation.
C++ defines constant evaluation to be the same as normal evaluation, although C++20 is adding a way to tell when you're evaluating at compile time so you can avoid things like inline asm at compile time.
constexpr doesn't even mean const_statement. All it means is don't emit an error if constant evaluation calls this function.
That is what bothers me about constexpr. It conflates compile-time evaluation with non-mutability. I want a keyword that guarantees an evaluation happens at compile-time, but doesn't by itself imply "const".
I'm not even sure what that would mean since the machinery to compute the value won't exist in the binary.
You can get this behavior by initializing a variable with the value of another variable whose value is a constexpr. This is a case in which the order of initialization of global variables is not ambiguous!
constexpr int foo_init_value = 2 + 4;
int foo = foo_init_value;
Actually not a bad idiom.
But like you I do wish you could apply constexpr-like behavior to expressions rather than just statements:
What you're If you could really apply really applied to expressions you could write something like
int foo = _compute_at_compile_time(2 + 4);
Of course the compiler can already do this degenerate example for you.
The first example is handled by constinit (or whatever we end up calling it) and the second is handled by consteval, although it has to be put in a function.
It doesn't even guarantee compile-time evaluation; it only guarantees that it can be evaluated at compile time. There is no guarantee for the compiler to actually do so --and some compilers will barf on complex constexpr. Future editions of C++ add consteval to ensure that it is evaluated at compile time.
Obviously when this happens it's a bug; the real question is "if such a bug occurs (i.e. the semantics of the program is affected by the use of constexpr) will it confuse the developer?"
Lisps (which have always intermixed interpreted and compiled code as long as lisp compilers have existed) have often struggled with this problem even though they have in many ways a simpler problem to address.
And since I'm writing about C++: I really love c++ but I hate the keyword "constexpr" as it's actually "const_statement". the distinction between statements and expressions, and the concomitant problem that expressions aren't first class, is a c-inherited botch on the language IMHO.
Edit: s/similar/simpler/