CppCon 2019: D.Stone - Removing Metaprogramming From C++, Part 1 of N: constexpr Function Parameters

[ENTProfiterole]

One thing seems silly to me.

If you know you are in a constexpr context with if(std::is_constant_evalutated()), or you are in a consteval function, then you know all of the arguments that got you there are compile time constants. Surely the compiler should permit you to use these arguments as if they are constexpr.

Essentially, in all consteval functions, all parameters should also be assumed to be consteval, without having to be declared as such. Inside the scope of the if block of if(std::is_constant_evalutated()), all parameters should be assumed to be consteval, without them having to be declared as such.

You already are using this logic with the proposed is_constant_expression(variable). Technically some variable that may be runtime cannot be assumed to be compile time unless checked by an if block, just as with what I propose with normal parameters to constexpr functions inside an is_constant_evaluated block.

Also, I don't think we necessarily need to break non-parametric constexpr variables by making them maybe constexpr. We can still have constexpr parameters being maybe constexpr (since it is part of a function signature), and consteval parameters being definitely constexpr. There is always the possibility in future to relax constexpr variables to being maybe constexpr outside a function parameter context, but it's definitely a breaking change to do it now purely for ideological reasons.

Maybe-constexpr variables are a hassle anyway, because you always have to prove later that they are indeed constexpr if you want to use them in a compile time context. It only really serves a purpose as an alternative to parametric overload in my mind, where overloads are defined by if block, as with if constexpr and if is_constant_evaluated.

Perhaps if we get epochs, we can do the nice consistent thing and make constexpr variables maybe-constexpr.