[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.