87

In C++17, this code is illegal:

constexpr int foo(int i) {
    return std::integral_constant<int, i>::value;
}

That's because even if foo can be evaluated at compile-time, the compiler still needs to produce the instructions to execute it at runtime, thus making the template instantiation impossible.

In C++20 we will have consteval functions, which are required to be evaluated at compile-time, so the runtime constraint should be removed. Does it mean this code will be legal?

consteval int foo(int i) {
    return std::integral_constant<int, i>::value;
}
curiousguy
  • 8,038
  • 2
  • 40
  • 58
Annyo
  • 1,387
  • 9
  • 20
  • AFAIK, no. `i` is (yet) not considered a core constant expression at that very moment. – L. F. May 14 '19 at 12:59
  • 2
    cppreference has *The consteval specifier declares a function or function template to be an immediate function [...] An immediate function is a constexpr function, and must satisfy the requirements applicable to constexpr functions or constexpr constructors, as the case may be.* so signs point to no. My reading of the standard leads me to the same conclusion but I'm not certain enough to state that in an answer. – NathanOliver May 14 '19 at 13:01
  • This question is being discussed on [meta](https://meta.stackoverflow.com/questions/411673). – cigien Sep 22 '21 at 15:23

3 Answers3

48

No.

Whatever changes the paper will entail, which is little at this point, it cannot change the fact that a non-template function definition is only typed once. Moreover, if your proposed code would be legal, we could presumably find a way to declare a variable of type std::integral_constant<int, i>, which feels very prohibitive in terms of the ODR.

The paper also indicates that parameters are not intended to be treated as core constant expressions in one of its examples;

consteval int sqrsqr(int n) {
  return sqr(sqr(n)); // Not a constant-expression at this  point,
}                     // but that's okay.

In short, function parameters will never be constant expressions, due to possible typing discrepancy.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
Columbo
  • 60,038
  • 8
  • 155
  • 203
  • 1
    Note that it does allow you to pass an argument of a `consteval` function to another `consteval` function, even though the argument is not technically a constant expression. – Nicol Bolas May 14 '19 at 13:31
  • @NicolBolas That's by permission on the side of immediate functions though, not on the side of the arguments. As you said: those aren't constant expressions, and template parameters require those for good reason. – Columbo May 14 '19 at 13:47
37

Does it mean this code will be legal?

consteval int foo(int i) {
    return std::integral_constant<int, i>::value;
}

No. This is still ill-formed. While consteval requires the call itself to be a constant expression, so you know that the argument that produces i must be a constant expression, foo itself is still not a template. Template?

A slight variation in your example might make this more obvious:

consteval auto foo(int i) {
    return std::integral_constant<int, i>();
}

Were this to be valid, foo(1) and foo(2) would... return different types. This is an entirely different language feature (constexpr function parameters) - because in order for this to work, such functions would really need to behave like templates.

It may seem a little unintuitive. After all, if the argument that produced i was a constant expression, surely i should be usable as one as well? But it's still not - there are no additional exceptions in [expr.const] that permit parameters for immediate functions. An immediate function is still just a function, and its parameters still aren't constant expressions -- in the same way that a normal constexpr function's parameters aren't constant expressions.

Of course with int, we can just rewrite the function to lift the function parameter into a template parameter:

template <int i>
consteval int foo() {
    return std::integral_constant<int, i>::value;
}

And C++20 gives us class types as non-type template parameters, so we can actually do this for many more types than we could before. But there are still plenty of types that we could use as a parameter to an immediate function that we cannot use as a template parameter - so this won't always work (e.g. std::optional or, more excitingly in C++20, std::string).

Barry
  • 286,269
  • 29
  • 621
  • 977
  • Can't we use a helper like `consteval int to_constexpr(int x) { return x; }`, and then `return std::integral_constant::value;` from (the non-templated version of) `foo()`? If yes, then current non-`constexpr`'ness of parameters looks like a useless restriction. – Ruslan May 14 '19 at 13:48
  • 1
    @Ruslan No. Because `to_constexpr(x)` is not a constant expression, which is allowed as it's inside a `consteval` function definition. – Columbo May 14 '19 at 13:49
9

It would seem that this will not be legal in C++20. A good explanation for why this would be problematic to support has already been given in the answers by @Barry and @Columbo (it doesn't really work with the type system). I'll just add what I believe to be the relevant quotes from the standard here that actually make this illegal.

Based on [temp.arg.nontype]/2

A template-argument for a non-type template-parameter shall be a converted constant expression […]

A converted constant expression is a constant expression that is implicitly converted to a particular type [expr.const]/7 (here, the type of the template parameter). So your question boils down to the question of whether a variable inside a consteval function is a constant expression. Based on [expr.const]/8

A constant expression is either a glvalue core constant expression that refers to an entity that is a permitted result of a constant expression (as defined below), or a prvalue core constant expression whose value satisfies the following constraints: […]

The expression i is a glvalue id-expression that is a core constant expression (because its evaluation does not do any of the things listed in [expr.const]/4). However, the entity this core constant expression refers to is not a permitted result of a constant expression [expr.const]/8:

An entity is a permitted result of a constant expression if it is an object with static storage duration that either is not a temporary object or is a temporary object whose value satisfies the above constraints, or if it is a non-immediate function.

The object in question is neither of static storage duration nor is it a temporary object…

Michael Kenzel
  • 15,508
  • 2
  • 30
  • 39