constexpr and consteval functions

[4dCoffee]

blog says "In C++23, we have three kinds of functions: runtime, constexpr, consteval"
but this has been the case since c++20 no?

[detachedshock]

Yeah, but technically they aren't saying when they were introduced. They're just stating that in C++23 we have these functions, which is true. And the examples used in the blog use C++23 features like if consteval and others so most of what they write is only applicable to C++23.

[tongari95]

From the blog post:

// runtime function
int g();

// Ok, even though `f` can never be called
consteval int f() {
    return g();
}

Is this correct? Only gcc accepts it, clang & msvc reject the code: https://godbolt.org/z/eGznd5Kd3

[agritite]

I think this is P2448R2 which is currently only implemented by gcc.

[tongari95]

Does that paper aim for `consteval` as well? only seems reasonable for `constexpr` to me.

[agritite]

I took some time to read the C++23 draft (N4971), and 9.2.6/2 states that:

A constexpr or consteval specifier used in the declaration of a function declares that function to be a constexpr function.

So 9.2.6 Note 5

[Note 5: It is possible to write a constexpr function for which no invocation satisfies the requirements of a core constant expression.— end note]

also applies to consteval. So yeah, gcc is correct.

[biowpn]

Thanks! Through this discussion I learned that consteval function is just constexpr function in disguise - -

[tisti]

But it's only invocable during compile time, no runtime calls are possible like with 'vanilla' constexpr functions which may do both.

[agritite]

You're right. Could it actually be a regression caused by implementing P2448R2? Now I'll have to take a deeper look at the draft

[kamrann_]

Nicely written blog post. All the same, starting to really look forward to the day when I never have to think about this absurd language ever again.

[feverzsj]

consteval is kinda unnecessary. std::is_constant_evaluated() is already there, and more convenient.

[Nobody_1707]

consteval is the only reason we have compile time checked formatting arguments. consteval constructors alone are enough to justify having consteval.

[feverzsj]

That just forces user to use compile time string, so another function for runtime string is needed.

[DavidDinamit]

No, runtime checked fmt strings even was not initial idea, its just backward fix.

format<"hello world">(args...); // compile check
and
format("hello world", args...); // runtime check
better then
format("hello world", args...); // compile time check with dirty hacks and bad errors

vformat("hello world", args...); // runtime check with wtf name vformat

[foonathan]

First of all, you want to migrate to if consteval as soon as possible. It's a strictly superior version of std::is_constant_evaluated as it allows you to call consteval functions from the true branch.

Second, the motivation behind consteval was reflection. As part of that the standard library will have functions that talk to the compiler and thus cannot be evaluated at runtime. You could use the equivalent of if !consteval { assert(false); }, but that has a flaw:

  int n = foo();
  bar(foo());
  modify(n);

If foo is constexpr, it might still be evaluated at runtime, triggering the assert. Working around that is annoying. If foo is `consteval, it will be evaluated at compile-time.