I would argue that the main value proposition of constexpr is not what the compiler can figure out automatically but allowing the developer to express where he wants constexpr and afterwards allow the compiler to verify if that's possible.
It's the difference between a soft "nice-to-have" requirements and a hard "must-have" requirement.
If you want to look at it that way, it only applies to variable declarations at best. Not function declarations, which is the most common case of where it's used (and it completely clutters the code).
And honestly, if that was the value proposition, they could've just done it a million other ways. Like think even 'template<auto V> static const auto constant = V' would let you do constant<whatever> and verify it at compile time. Yeah it's C++20 but they could've still done it then or used a different approach, there are lots of ways to address this (attributes, etc.). No need to clutter every function prototype in the language for something that small.
Also I think you're thinking more of consteval than constexpr.
Not really. The whole point of constexpr is to state that an expression is constant, thus the value returned by the function is computed at compile time.
> And honestly, if that was the value proposition, they could've just done it a million other ways.
To me it seems thay annotating a function with constexpr is the clearest and most straight-forward way to go about expressing constant expressions.
> Also I think you're thinking more of consteval than constexpr.
To each his own, but if the whole point is to represent constant expressions then the constexpr keyword seems to be straight-forward.
That's not even one point of constexpr, let alone the whole point. Putting constexpr in front of a function declaration does absolutely nothing to the codegen. See for yourself: https://gcc.godbolt.org/z/34h6Tanzn
Notice that both h() and f() are called despite being constexpr.
> To me it seems thay annotating a function with constexpr is the clearest and most straight-forward way to go about expressing constant expressions.
Again, it doesn't do what you think (see above). It does absolutely nothing to a function.
> To each his own, but if the whole point is to represent constant expressions then the constexpr keyword seems to be straight-forward.
This isn't an opinion thing. The consteval literally does what you're imagining constexpr does. Just replace constexpr with consteval in the code above. (I could probably argue that one has little use too, but that's not what I'm arguing here.)
But consteval function is also not a literal replacement constexpr. For example, you can't take a pointer to the former. There's a reason they co-exist and are not useless.
consteval wasn't intended to be excusing anything. I was just letting you know you're misunderstanding what constexpr does, and that what you're thinking it's supposed to do is in fact consteval's job.
You seem very confused about language specifications. That GCC and Clang happen to interpret constexpr as an extra "please inline" hint under -O3 is not evidence of constexpr "doing" something, and certainly not justification for including it in the language standard. That's like saying HN's orange color is "doing something" just because you really like to go eat an orange every time you see it.
I suspect you will have a hard time finding any evidence that constexpr was ever intended to be a "this is technically optional but please really, really try to inline this" hint of sorts to the compiler by the committee.
> But consteval function is also not a literal replacement constexpr.
I didn't say it was.
> For example, you can't take a pointer to the former.
"Therefore constexpr is useful" does not follow from this.
> There's a reason they co-exist and are not useless.
There's a mediocre reason for consteval, and a bad reason for constexpr. The former is probably unnecessary IMO though still of marginal utility, and in any case I can concede there's a debate that could be had there. The latter would be practically useless if the language cared to just make it the implicit default. It's really only solving a problem it created.
If you're using constexpr as an "optional but highly recommended inline" hint like you're showing me in your examples, you're doing the equivalent of pulling up HN's orange color so it coaxes you (or someone else) to go eat an orange. You are certainly welcome do that (hopefully it's a free country where you live) and I'm not stopping you per se, but it's missing both the letter and the spirit of the keyword(/color) by a colossal margin.
Because whether a call should be CTE'd is a decision for the caller to make, not the callee.
> I actually really like seeing if a library function can be cte'd.
That's not what you're seeing with constexpr. It's what you're seeing with consteval. [1]
What you're seeing with constexpr is which functions are prohibited from being CTE'd. Which is pretty useless when you don't intend to CTE them in the first place, and actively counterproductive when you do.
[1] Actually this is kind of a lie too [2], but at least it's much closer to the truth.
[2] Notice that seeing consteval here tells you absolutely nothing: https://gcc.godbolt.org/z/bWzd4v6Y1
See this code:
>> [1] Actually this is kind of a lie too [2], but at least it's much closer to the truth.
>> [2] Notice that seeing consteval here tells you absolutely nothing: https://gcc.godbolt.org/z/bWzd4v6Y1
Note I didn't claim this was their only difference.
The problem was explained here: https://news.ycombinator.com/item?id=28895123
The language could just say everything that could be constexpr is implicitly constexpr, and you'd get just as useful of an effect (even on existing code!) without anyone having to do anything extra. It's very rare for a function that could be constexpr to be justifiably prohibited from being used as such, and they could've introduced an opt-out attribute for that if they really cared.
constexpr is an interface guarantee. If it were not there the entire optimization stack would become brittle. Imagine updating a dependency or rewriting a function and suddenly your program is 10x slower. Things like this are known in other languages. For example Haskell and fusion optimization. It's fine for you to disagree with this reasoning. But then you should not be using C++ as you don't really care for performance and can use many other better suited languages.
Then you say constexpr doesn't make it possible for the caller to specify whether something is cte'd while this is precisely what the caller decides. You are confusing constexpr and consteval. consteval doesn't make it possible for the caller to decide whether the function is cte'd.
Please answer the points I have brought up instead of simply referring to something I have already refuted.
That can already happen and will still be possible after constexpr. And it was always preventable by forcing evaluation of the variable in a CTE context, like in std::integral_constant. And you're missing the fact that an implicit constexpr with an explicit opt-out needn't behave any differently from one with explicit opt-in. Same semantics, just fewer keystrokes.
> constexpr is an interface guarantee
> Please answer the points I have brought up instead of simply referring to something I have already refuted.
You didn't actually refute it (though you tried), and I already did address them:
>> [2] Notice that seeing consteval here tells you absolutely nothing: https://gcc.godbolt.org/z/bWzd4v6Y1
Replace consteval with constexpr and you'll see it told you absolutely nothing about bar()'s CTE'ability. Observe how the callee used constexpr and bar() failed to CTE despite being constexpr: https://gcc.godbolt.org/z/odqbT7x9j
> You are going in circles...
Because you went in circles. I've directly addressed every single one of your points but then you looped back to ask the same question as you did in the beginning. Same questions, same answers.
In that example marking bar as consteval does nothing. Because you are not ever calling bar... Calling bar shows that it's not possible because foo is not constexpr:
note: non-constexpr function 'foo<int>' cannot be used in a constant expression
consteval T bar(T x) { return foo(x); }
> Replace consteval with constexpr and you'll see it told you absolutely nothing about bar()'s CTE'ability. Observe how the callee used constexpr and bar() failed to CTE despite being constexpr: https://gcc.godbolt.org/z/odqbT7x9j
It doesn't compile because foo is not constexpr. Marking foo as constexpr makes it compile and foo and bar are evaluated at compile time. It produces this ASM:
main: # @main
pushq %rbp
movq %rsp, %rbp
movl $0, -4(%rbp)
movl $0, -8(%rbp)
xorl %eax, %eax
popq %rbp
retq
> It doesn't compile because foo is not constexpr.
Well obviously. That's not the question here. The question is, explain to me exactly what guarantee the declaring bar() as 'constexpr' achieved for anyone? It clearly didn't prevent its author from calling a non constexpr function, and it clearly didn't signal to its users that it is usable from a constexpr context either. The user had to go inspect each one of its callees manually to see if they could all be evaluated at compile time in reality, which is exactly what you just did with foo(). Which is pretty damn hard (as in, Turing-undecidably-hard) when things are templates and you have ADL on top of that. And which the presence of constexpr on bar() didn't help you one bit with.
The declaration of bar() told you exactly nothing by having constexpr in it. It made no difference whatsoever for itself, nor for main(). It just added clutter.
You can point out that it failed to compile, and that can be a benefit when compiling would've been detrimental. Just like you yourself literally just did when you said "The code doesn't compile [...]".
> it did in fact stop the author from calling a non-constexpr function from a constexpr function.
The constexpr in front of bar() is not what prevented compilation. You don't believe me? Just take it out and see. The code would've failed to compile the exact same way without constexpr in front of bar(). Try it before disagreeing with me.
You're saying putting constexpr in front of bar() has a benefit. I'm saying: tell me what it was. Making that constexpr be always in front of bar() implicitly would've resulted in exactly the same outcome in every situation where the code compiles and also where it fails to compile (like above). Nothing would've been any different. I don't get why this is so difficult but I'm not going to keep repeating myself. Everything I can possibly imagine explaining is in my comments up to this point so just re-read them, I have no other way I can phrase these. Everyone else has understood what I'm saying and I'm at a loss how else to explain it differently. I promise you it's not wrong, we're just failing to communicate.
Unfortunately it isn't a direction WG21 is willing to adopt.