1 Introduction

[P1240R2] proposes that we should use a monotype, std::meta::info, as part of a value-based reflection. One argument here is that lots of operations return ranges of meta::info and it would be valuable if we could simply reuse our plethora of existing range algorithms for these use-cases.

Let’s investigate this claim.

We don’t need a working implementation of P1240 to test this, it’s enough to have this very, very loose approximation:

namespace std::meta {
    struct info { int value; };

    consteval auto is_invalid(info i) -> bool {
        // we do not tolerate the cult of even here
        return i.value % 2 == 0;
    }
}

And let’s pick a simple problem. We start some sequence of… we’ll call them types:

constexpr std::meta::info types[] = {1, 3, 5};

We want to ensure that none of them are invalid. This is a problem for which we have a direct algorithm: none_of. Let’s try using it:

static_assert(std::ranges::none_of(
    types,
    std::meta::is_invalid
));

static_assert(std::ranges::none_of(
    types,
    [](std::meta::info i) {
        return std::meta::is_invalid(i);
    }
));

static_assert(std::ranges::none_of(
    types,
    [](std::meta::info i) consteval {
        return std::meta::is_invalid(i);
    }
));

static_assert(std::ranges::none_of(
    types,
    +[](std::meta::info i) consteval {
        return std::meta::is_invalid(i);
    }
));

That exhausts the options here. What if instead of trying to directly static_assert the result of an algorithm (or, equivalently, use it as an initializer for a constexpr variable or as the condition of an if constexpr or as a non-type template argument), we did it inside of a new consteval function?

consteval auto all_valid() -> bool {
    return std::ranges::none_of(
        types,
        std::meta::is_invalid
    );
}
static_assert(all_valid());

consteval auto all_valid() -> bool {
    return std::ranges::none_of(
        types,
        [](std::meta::info i) {
            return std::meta::is_invalid(i);
        }
    );
}
static_assert(all_valid());

consteval auto all_valid() -> bool {
    return std::ranges::none_of(
        types,
        [](std::meta::info i) consteval {
            return std::meta::is_invalid(i);
        }
    );
}
static_assert(all_valid());

consteval auto all_valid() -> bool {
    return std::ranges::none_of(
        types,
        +[](std::meta::info i) consteval {
            return std::meta::is_invalid(i);
        }
    );
}
static_assert(all_valid());

This leaves a lot to be desired. The only mechanism completely sanctioned by the language and library rules we have today is to write a bespoke consteval function which invokes the algorithm using a non-generic, consteval lambda that just wraps an existing library function and converts it to a function pointer.

Put simply: algorithms are basically unusable with the consteval rules we have.

2 consteval is a color

The problem is that consteval is a color [what-color]. consteval functions and function templates can only be called by other consteval functions and function templates.

std::ranges::none_of, like all the other algorithms in the standard library, and probably all the other algorithms outside of the standard library, are not consteval functions or function templates. Moreover, none of these algorithms are ever going to either become consteval or be duplicated in order to gain a consteval twin. Which means that none of these algorithms, including none_of, can ever invoke any of the facilities proposed by [P1240R2].

2.1 Some code is already multi-colored

Almost.

One of the new C++23 features is if consteval [P1938R3], which partially alleviates the consteval color problem. That facility allows consteval functions to be called by constexpr functions in a guarded context, largely in order to solve the same sort of problem that std::is_constant_evaluated() [P0595R2] set out to solve except in a way that would now allow you to invoke consteval functions.

The way it works is by establishing an immediate function context. This is important because the rule we were constantly running up against was that:

13 An immediate invocation shall be a constant expression.

And a call to an immediate function that is in an immediate function context is not an immediate invocation.

In our case here, we’re not trying to choose between a compile-time friendly algorithm and a run-time efficient one. We’re only trying to write compile-time code. But that’s okay, there’s no rule that says you need an else:

static_assert(std::ranges::none_of(
    types,
    [](std::meta::info i) {
        if consteval {
            return std::meta::is_invalid(i);
        }
    }));

static_assert(std::ranges::none_of(
    types,
    [](std::meta::info i) consteval {
        if consteval {
            return std::meta::is_invalid(i);
        }
    }));

So… this is fine. We can still use consteval functions with lambdas, as long as we just wrap all of our lambda bodies in if consteval (but definitely also not make them consteval - they’re only kind of consteval).

2.2 Making the library multi-colored

We could avoid putting the burden of sprinkling their code with if consteval by pushing all of these extra calls into the library.

For instance, we could make this change to none_of:

template <ranges::input_range R, class Pred>
constexpr auto ranges::none_of(R&& r, Pred pred) -> bool {
    auto first = ranges::begin(r);
    auto last = ranges::end(r);
    for (; first != last; ++first) {
        if (pred(*first)) {
            return false;
        }
    }
    return true;
}

template <ranges::input_range R, class Pred>
constexpr auto my::none_of(R&& r, Pred pred) -> bool {
    auto first = ranges::begin(r);
    auto last = ranges::end(r);
    for (; first != last; ++first) {
        if consteval {
            if (pred(*first)) {
                return false;
            }
        } else {
            if (pred(*first)) {
                return false;
            }
        }
    }
    return true;
}

But unfortunately that doesn’t actually work. If pred(*first) were actually a consteval call, then even duplicating the check in both branches of an if consteval doesn’t help us. The call to pred(*first) in the first sub-statement (the case where we are doing constant evluation) is fine, since now we’re in an immediate function context, but the call to pred(*first) in the second sub-statement (the “runtime” case) is just as problematic as it was without the if consteval.

So the attempted solution on the right isn’t just ridiculous looking, it also doesn’t help. The only library solution here (and I’m using the word solution fairly loosely) is to have one set of algorithms that are constexpr and a completely duplicate set of algorithms that are consteval.

This has to be solved at the language level.

2.3 Making the language multi-colored

Let’s consider the problem in a very local way, going back to the lambda example and presenting it instead as a function (in order to simplify things a bit):

constexpr auto pred_bad(std::meta::info i) -> bool {
    return std::meta::is_invalid(i);
}

constexpr auto pred_good(std::meta::info i) -> bool {
    if consteval {
        return std::meta::is_invalid(i);
    }
}

As mentioned multiple times, pred_bad is ill-formed today because it contains a call to an immediate function outside a consteval context and that call isn’t a constant expression. That is one way we achieve the goal of the consteval functions that they are only invoked during compile time. But pred_good is good because that call only appears in an if consteval branch (i.e. a consteval context), which makes the call safe.

What’s interesting about pred_good is that while it’s marked constexpr, it’s actually only meaningful during compile time (in this case, it’s actually UB at runtime since we just flow off the end of the function). So this isn’t really a great solution either. We need to ensure that pred_good is only called at compile time.

But we have a way to ensure that: consteval.

Put differently, pred_bad is today ill-formed, but only because we need to ensure that it’s not called at runtime. If we could ensure that, then we calling it during compile time is otherwise totally fine. What if the language just did that ensuring for us? If such constexpr functions, that are only ill-formed because of calls to consteval functions simply became consteval, then we gain the ability to use them at compile time without actually losing anything - we couldn’t call them at runtime to begin with.

3 Proposal

This paper proposes avoiding the consteval coloring problem (or, at least, mitigating its annoyances) by allowing certain existing constexpr functions to implicitly become consteval functions when those functions can already only be invoked during compile time anyway.

Specifically, these three rules:

1. If a constexpr function contains a call to an immediate function outside of an immediate function context, and that call itself isn’t a constant expression, said constexpr function implicitly becomes a consteval function. This is intended to include lambdas, function template specializations, special member functions, and should cover member initializers as well.

2. If an expression-id designates a consteval function without it being an immediate call in such a context, it also makes the context implicitly consteval. Such expression-id’s are also allowed in contexts that are manifestly constant evaluated.

3. Other manifestly constant evaluated contexts (like constant-expression and the condition of a constexpr if statement) are now considered to be immediate function contexts.

With these rule changes, no library changes are necessary, and any way we want to write the original call just works:

static_assert(std::ranges::none_of(
    types,
    [](std::meta::info i) {
        return std::meta::is_invalid(i);
    }));

static_assert(std::ranges::none_of(
    types,
    [](std::meta::info i) consteval {
        return std::meta::is_invalid(i);
    }));

static_assert(std::ranges::none_of(
    types,
    std::meta::is_invalid
));

static_assert(std::ranges::none_of(
    types,
    +[](std::meta::info i) consteval {
        return std::meta::is_invalid(i);
    }
));

static_assert(std::ranges::none_of(
    types,
    []{
        return std::meta::is_invalid;
    }()
));

3.1 Implementation Experience

This has been implemented in EDG by Daveed Vandevoorde. One interesting example he brings up:

consteval int g(int p) { return p; }
template<typename T> constexpr auto f(T) { return g; }
int r = f(1)(2);      // proposed ok
int s = f(1)(2) + r;  // error

Today, even the call f(1) is ill-formed, because naming g isn’t allowed in that context (it is neither a subexpression of an immediate invocation nor in an immediate function context).

Per the proposal, the initialization of r becomes valid. f implicitly becomes a consteval function template due to use of g. Because r is at namespace scope, we tentatively try to perform constant initialization, which makes the initial parse manifestly constant evaluated. In such a context, f(1) does not have to be a constant expression, so the fact that we’re returning a pointer to consteval function is okay. The subsequent invocation g(2) is fine, and initializes r to 2.

But even with this proposal, the initialization of s is ill-formed. The tentative constant initialization fails (because r isn’t a constant), and in the subsequent dynamic initialization, f(1) is now actually an immediate invocation (f still becomes implicitly consteval, which now must be a constant expression, which now has the rule that its result must be a permitted result, in which context returning a pointer to consteval function is disallowed).

3.2 Wording Circularity

One of the issues with actually wording this proposal is its chicken-and-egg nature. Let’s consider the main example again:

[](std::meta::info i) {
    return std::meta::is_invalid(i);
}

And let’s work through both the status quo reasoning and the proposed reasoning.

Essentially, we have a flow of reasoning that starts with a function not being an immediate function and, because of that, becoming an immediate function. This is, admittedly, confusing. But I think it does make sense, and Daveed had less trouble implementing this than we had even attempting to try to reason about wording it.

4 Wording

This wording is known to be incomplete at this point, the primary goal in this revision is to at least set the stage so that people can understand the intent. The crux of the wording change is to extend 7.7 [expr.const]/13:

13 An expression or conversion is in an immediate function context if it is potentially evaluated and either:

• (13.1) its innermost enclosing non-block scope is a function parameter scope of an immediate function, or
• (13.2) it is a subexpression of a manifestly constant-evaluated expression or conversion, or
• (13.3) its enclosing statement is enclosed ([stmt.pre]) by the compound-statement of a consteval if statement ([stmt.if]).

13a An expression or conversion is immediate-escalating if it is not initially in an immediate function context and it is either

• (13a.1) a potentially-evaluated id-expression that denotes an immediate function, or
• (13a.2) a potentially-evaluated explicit or implicit invocation of an immediate function that is not a constant expression.

13b An immediate-escalating function is:

• (13b.1) the call operator of a lambda that is declared with neither the constexpr nor consteval specifiers,
• (13b.2) a defaulted special member function that is declared with neither the constexpr nor consteval specifiers, or
• (13b.3) a function that results from the instantiation of a templated entity defined with the constexpr specifier.

13c An immediate function is a function or constructor that is:

• (13c.1) declared with the consteval specifier, or
• (13c.2) an immediate-escalating function, F, that contains an immediate-escalating expression, E, such that E’s innermost enclosing non-block scope is F’s function parameter scope.

An expression or conversion is an immediate invocation if it is a potentially-evaluated explicit or implicit invocation of an immediate function immediate-escalating and is not in an immediate function context. An immediate invocation shall be a constant expression.

With which we can remove 7.5.4.1 [expr.prim.id.general]/4, which is now handled in the above:

4 A potentially-evaluated id-expression that denotes an immediate function shall appear only

• (4.1) as a subexpression of an immediate invocation, or
• (4.2) in an immediate function context.

And removing the current definition of immediate function from 9.2.6 [dcl.constexpr]/2, since it’s now defined (recursively) above.

2 A constexpr or consteval specifier used in the declaration of a function declares that function to be a constexpr function. [Note: A function or constructor declared with the consteval specifier is called an immediate function ([expr.const]) -end note ]. A destructor, an allocation function, or a deallocation function shall not be declared with the consteval specifier.

5 Acknowledgments

Thanks to Daveed Vandevoorde and Tim Song for discussions around this issue and Daveed for implementing it.

6 References