std::is_constant_evaluated behavior

Question

GCC9 already implements std::is_constant_evaluated. I played a little bit with it, and I realized it is somewhat tricky. Here’s my test:

constexpr int Fn1()
{
  if constexpr (std::is_constant_evaluated())
    return 0;
  else
    return 1;
}

constexpr int Fn2()
{
  if (std::is_constant_evaluated())
    return 0;
  else
    return 1;
}

int main()
{
  constexpr int test1 = Fn1(); // Evaluates to 0
  int test2 = Fn1();           // Evaluates to 0
  int const test3 = Fn1();     // Evaluates to 0

  constexpr int test4 = Fn2(); // Evaluates to 0
  int test5 = Fn2();           // Evaluates to 1
  int const test6 = Fn2();     // Evaluates to 0
}

According to these results, I extracted the following conclusions:

• if constexpr (std::is_constant_evaluated()) always evaluates the true branch. Therefore, it makes no sense to use this construct.

• If the compiler evaluates a variable at compile time, std::is_constant_evaluated()) is true, no matter whether that variable is explicitly annotated constexpr or not.

Am I right?

Answer 1

if constexpr requires a constant expression for a condition. So is_constant_evaluated is of course always going to be true in such a context.

It's meant for a regular if. The purpose is to not go into a code path that is illegal in a constexpr function when evaluated in a constant expression. But to let it execute in runtime. It's not there to eliminate those code paths from the function altogether.

Answer 2

Here's how I think about this, maybe you'll find this helpful... maybe not. Note that I think writing if constexpr (std::is_constant_evaluated()) will be a really common error, and it's an easy trap to fall into. But hopefully compilers will just diagnose that case. Submitted 91428, which is fixed for gcc 10.1.

---

We essentially have two different rules for code - the typical rules for normal runtime code, and the restrictions for constant expressions that are for constexpr programming. Those are the expr.const restrictions: no UB, no reinterpret_cast, etc. Those restrictions keep decreasing from language standard to language standard, which is great.

Basically, control flow (from a code path perspective) alternates between being in the "full runtime" mode and the constexpr mode. Once we enter the constexpr mode (whether by initializing a constexpr object or evaluating a template parameter or ...), we stay there until we're done... and then we're back to full runtime mode.

What is_constant_evaluated() does is simply: Am I in constexpr mode? It tells you if you're on a context that requires constant expressions.

In that view, let's look at if constexpr (is_constant_evaluated()). Regardless of what state we used to be in, if constexpr requires a constant expression as its initialized so this lifts us into constexpr mode if we weren't there already. Hence, is_constant_evaluated() is just true - unconditionally.

However, for if (is_constant_evaluated()), a simple if doesn't change our state between runtime and constexpr. So the value here depends on the context it was called from. Initializing test4 puts us onto constexpr mode because it's a constexpr object. For the duration of its initialization, we follow the constant expression rules... so is_constant_evaluated()is true. But once we're done, we're back to runtime rules... so in the initialization of test5, is_constant_evaluated() is false. (And then test6 is an unfortunate language special case - you can use constant integral variables as constant expressions, so we treat their initialization the same way for these purposes.)