How can this code be constexpr? (std::chrono)

Question

In the standards paper P0092R1, Howard Hinnant wrote:

template <class To, class Rep, class Period,
          class = enable_if_t<detail::is_duration<To>{}>>
constexpr
To floor(const duration<Rep, Period>& d)
{
    To t = duration_cast<To>(d);
    if (t > d)
        --t;
    return t;
}

How can this code work? The problem is that operator-- on a std::chrono::duration is not a constexpr operation. It is defined as:

duration& operator--();

And yet this code compiles, and gives the right answer at compile time:

static_assert(floor<hours>(minutes{3}).count() == 0, "”);

What's up with that?

Answer 1

The answer is that not all operations in a compile-time routine have to be constexpr; only the ones that are executed at compile time.

In the example above, the operations are:

hours t = duration_cast<hours>(d);
if (t > d) {} // which is false, so execution skips the block
return t;

all of which can be done at compile time.

If, on the other hand, you were to try:

static_assert(floor<hours>(minutes{-3}).count() == -1, "”);

it would give a compile-time error saying (using clang):

error: static_assert expression is not an integral constant expression
        static_assert(floor<hours>(minutes{-3}).count() == -1, "");
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: non-constexpr function 'operator--' cannot be used in a constant expression
                        --t;
                        ^
note: in call to 'floor(minutes{-3})'
        static_assert(floor<hours>(minutes{-3}).count() == -1, "");

When writing constexpr code, you have to consider all the paths through the code.

P.S. You can fix the proposed floor routine thusly:

template <class To, class Rep, class Period,
          class = enable_if_t<detail::is_duration<To>{}>>
constexpr
To floor(const duration<Rep, Period>& d)
{
    To t = duration_cast<To>(d);
    if (t > d)
        t = t - To{1};
    return t;
}

Answer 2

Under the rules of n3597 and n3652, expressions inside a constexpr function do not themselves have to be constant expressions, as long as they don't modify globally visible state.

There's an example of

constexpr int f(int a) {
  int n = a;
  ++n;                  // '++n' is not a constant expression
  return n * a;
}
int k = f(4);           // OK, this is a constant expression.
                        // 'n' in 'f' can be modified because its lifetime
                        // began during the evaluation of the expression.

Most likely these are the rules that Howard Hinnant followed when writing the paper you mention.

In order to work with the duration<T> code in the question, operator-- would have to be made a constexpr function. Since constexpr changes to the library were not final, it's easy to understand how Howard could have relied on such a change.