Hacker News Reader

Comment by mnarayan01 | Hacker News Reader

> Doesn't making a variable constexpr ensure it is a compile time value

It ensures that the variable could be evaluated at compile time, where "could be evaluated at compile time" means "conforms to the rules set forth in the C++ standard". Whether or not it is computed at compile time is dependent on the compiler.

View on HN

> It ensures that the variable could be evaluated at compile time

Why couldn't a variable without constexpr be evaluated at compile-time? Nobody ever explains this.

There's precedent in C++ for keywords that give the compiler hints it doesn't necessarily promise to act on: inline.

Happy to be corrected (EDIT: indeed, I stand corrected! see replies below), but I don't think the C++ spec says anything about 'inline' encouraging the compiler to inline the compiled code?

'auto' would've been an example, but that also got removed, because they realized it was useless. I don't get how constexpr is any different.

I don't know my way around the spec, but Wikipedia is pretty unequivocal:

"... it serves as a compiler directive that suggests (but does not require) that the compiler substitute the body of the function inline by performing inline expansion, i.e. by inserting the function code at the address of each function call, thereby saving the overhead of a function call."

https://en.wikipedia.org/wiki/Inline_function

Thanks for this! I was very skeptical, but you made me look through every single mention of the word 'inline' in the spec, and you are indeed correct. :) Here is the relevant quote:

> [7.1.2] [dcl.fct.spec] A function declaration with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by shall still be respected

Shameless pedant kneejerk: 'inline' has semantics in additional to the optimization-hint. e.g. inlined functions won't trigger multiple-definition link-errors, even if they're left as ordinary functions in the executable.

The option was discussed during standardization. It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation.

It might not be a great reason (some code becomes a keyword soup with all the pointless boilerplate, we really need a DWIM[1] keyword).

[1] Declare With Implicit Meaning of course.

> It is expected that some corners of the language will never be available at compile time, for example I/O.

So you're saying functions that have side-effects like I/O can actually perform those operations at compile-time if marked with constexpr?

No: the purpose of constexpr is that the compiler would issue an error if a constexpr function contains such side-effects.

No? Wouldn't it do that with a static_assert invoking the function too?

No sure I get the question: static_assert can only invoke constexpr functions, and constexpr functions can only call themselves other constexpr functions. Since IO functions are not constexpr, you can't call them there.

(EDIT to my last comment since I can't actually edit it -- I'm not sure if I misinterpreted your comment earlier or if you updated yours, but this is my updated reply.)

> It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation.

Don't compilers already require the implementation of a function to be there in order to evaluate the code at compile-time? And don't they already have to verify that it can indeed be called at compile-time? I don't really get what the constexpr flag helps the compiler. It could just assume everything is constexpr implicitly unless proven otherwise.

constexpr isn't just a claim about today - it's a promise for the future. That is, the compiler can certainly notice that a function can be evaluated at compile time, and indeed optimizers will often perform enough inlining and constant propagation to boil down function calls to constant values in the binary. The constexpr keyword serves two purposes: it claims that the implementation is usable in constant expressions today (therefore allowing compilers to diagnose (i.e. emit compiler errors for) things that can't be done at compiletime, like I/O), and it promises that the implementation won't change in the future to be hostile to compile-time evaluation. This promise is important - otherwise, users could take a dependency on a function's current behavior (e.g. by using its result as an array bound, or as a template argument), and then they would be broken by implementation changes in the future that prohibited compile-time evaluation.

I see, so you're saying it's a verifiable promise by the function writer that it can be evaluated at compile-time?

Meaning its entire purpose is to just be an easier version of a compile-time unit-test like static_assert(f(1) == 2)?

Beautifully put. This is what's missing from D's approach.

Reply on news.ycombinator.com