> "How will you differentiate a call that you want to perform at compile-time vs at run-time [without constexpr]?" right, I should have wrote "in a constexpr c

> "How will you differentiate a call that you want to perform at compile-time vs at run-time [without constexpr]?" right, I should have wrote "in a constexpr context", e.g. what you find in template<invocations>, etc. > And I've been replying to that by pointing out that your run-time code can still be evaluated at compile time even if you don't use constexpr. I don't understand what this does have to do with the rest. That's just an optimization (which is not "consistently observable" and depends on the whims of the compiler). Making a variable constepxr is something that causes consistently observable results, which is much more useful. Incidentally, I have had multiple cases where things that could obviously be computed at compile-time weren't optimized in such a way by clang or gcc unless I did constexpr auto foo() { constexpr auto bar = some_complicated_function(...); return bar; } instead of constexpr auto foo() { return some_complicated_function(...); } with constexpr, if the compiler cannot compute the thing at compile time I get an error (which is good !) > You seem to be desiring consteval when you talk about constexpr. what I actually desire deep down is a way to have aribtrary parametrisable contexts, something like a generalized version of http://www.jot.fm/issues/issue_2008_03/article4/ http://www.jot.fm/issues/issue_2008_03/article4/ ; having two is already a good start. > (And you still haven't addressed the fact that your unit-test example is better served by having two separate functions!) well, because I disagree. If the name my function is e.g. strlen I definitely don't want a strlen_constexpr and strlen_nonconstexpr pair of functions, I want the good choice to be made depending on the context I'm in ; I want to write "strlen" in generic code and have the correct thing happen no matter what. to give you my general perspective, constexpr could call itself super_bamboozle that I couldn't care less, I just want "multiple worlds" being available in my programming language. what name they take is of very little importance.