[Jasper_]

Except constexpr isn't a guarantee. Compilers can choose to silently evaluate constexpr things at runtime. And I have ran into this before: a compiler with a recursion limit causing it to bail on constexpr and just emit the code.

So constexpr isn't a guarantee of it being evaluated at compile time, and non-constexpr isn't a guarantee of it being evaluated at runtime. Cool, huh?

[jcelerier]

> constexpr isn't a guarantee of it being evaluated at compile time

constexpr is a guarantee that you can use the thing in a constexpr context, and this is where the "evaluated at compile-time" guarantee can come from:

    template<typename T>
    auto func() {
      // here some compilers can still choose to evaluate x at run-time - and very likely all of them if no optimizations are enabled
      constexpr int x = f(); 

      // but here it becomes mandatory for this use of x to be evaluated at compile-time, since the number is literally going to be part of the compiled binary as part of the function name mangling
      return std::integral_constant<int, x>{};
    }

[gpderetta]

Constexpr does not guarantee that a constexpr function can be called at compile time, unfortunately. Only that it can be called at runtime for a subset of all possible parameters.

Except of course the subset of parameters for which it is constexpr callable can't be checked at function definition time (if it exists at all), only at function invocation time.

Which makes the constexpr annotation useless and it is in only because the authors couldn't otherwise get the paper through some committee objections.

[Dylan16807]

Is such a mangling mandated by the standard?

[mhh__]

Mangling is mentioned in the standard.

In this case though the underlying reason is that its part of the type (system) not because of the mangle specifically.

[Dylan16807]

> Mangling is mentioned in the standard.

Forgive me, but can you be clearer than "mentioned"? Is the mangling required to contain template parameters for return types?

> In this case though the underlying reason is that its part of the type (system) not because of the mangle specifically.

I'm not sure. The compiler knows it will always be the same type, so under many uses of this function I could easily imagine a compiler that doesn't actually fill in .value until runtime.

[jcelerier]

> Forgive me, but can you be clearer than "mentioned"? Is the mangling required to contain template parameters for return types?

The mangling will contain template parameters, as you can have:

foo.hpp

    template<typename T>
    T f();

foo.cpp

    template<>
    int f<int>() { return 123; }
    template<>
    float f<float>() { return 123; }

bar.cpp

    std::cout << f<int>();

and the right function has to be found. demo: https://gcc.godbolt.org/z/rMjYoEzaK

[Dylan16807]

Sorry, I meant parameters that only are being returned, and not passed in.

So in the example several layers above, T uniquely identifies the function. I don't see any need to involve std::integral_constant<int, x> in the mangling.

[mhh__]

Mangling isn't technically required as per se but it's by far the most common approach (basically a local minimum in terms of cost)

I think this subset of C++ templates is probably undecidable still.

[masklinn]

Mostly makes sense to me: constexpr means the function is evaluatable at compile-time, being callable at runtime is part of the contract and why adding constexpr does not change the API.

For an assertion that something is evaluated at compile time I’d assume a variable-level annotation (in a non-constexpr function). Though I don’t know c++ enough to have any idea whether that’s the case.

And contant evaluation optimisation has always been a thing so it’s not really surprising.

[Dylan16807]

> Mostly makes sense to me: constexpr means the function is evaluatable at compile-time, being callable at runtime is part of the contract and why adding constexpr does not change the API.

The problem isn't that you're able to call it at runtime with runtime data, it's that if you give it compile-time data you have no idea when it will be run.

> For an assertion that something is evaluated at compile time I’d assume a variable-level annotation (in a non-constexpr function). Though I don’t know c++ enough to have any idea whether that’s the case.

Oh, were you under the impression that constexpr was just for functions? It applies to variables too, and it's not a guarantee on them. You need to use other, newer annotations.

[comex]

C++20 has consteval and constinit to fix this (at the cost of making things even more complicated).

[MrBuddyCasino]

Amazing.