6 ms·

Is it superfluous? I will admit that when I first read about constexpr my first thought was 'why can't the compiler figure this out automatically?'. I assume th

Is it superfluous? I will admit that when I first read about constexpr my first thought was 'why can't the compiler figure this out automatically?'. I assume that compiler vendors all agreed that a new keyword was necessary, they don't add them without reason.

rowanG077 5y ago
The compiler can figure it out. But that doesn't solve the problem constexpr was created for. Without constexpr compile time evaluation becomes very brittle. Constexpr is there to help the compiler and developer reach an understanding of the stuff that has to be evaluated at compile time.
- atq2119 5y ago
  The problem is that (especially library) code just becomes absolutely littered with constexpr, because realistically speaking, you do want everything that can be constexpr to actually be constexpr.
  - rowanG077 5y ago
    Why is that a problem? I actually really like seeing if a library function can be cte'd.
    - dataflow 5y ago
      > Why is that a problem? 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 https://gcc.godbolt.org/z/bWzd4v6Y1
      - rowanG077 5y ago
        consteval says it MUST be constant evaluated not that it CAN be constant evaluated. That is very different. With consteval it's not up to the caller to make the decision of whether to run at compile-time or not, the caller must provide constexpr arguments. With just a constexpr annotation the caller can decide to run it either at compile-time or run-time. See this code: https://godbolt.org/z/oMWKcWW5e https://godbolt.org/z/oMWKcWW5e
        dataflow 5y ago
        Like I said: >> [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 https://gcc.godbolt.org/z/bWzd4v6Y1 Note I didn't claim this was their only difference.
        rowanG077 5y ago
        I don't see what's your problem with libraries marking their functions as constexpr then. The library says it's up to the caller to decide whether this function is constant evaluated. Precisely what you wanted. If libraries start marking their function as consteval. Now that would be a problem.
        dataflow 5y ago
        > I don't see what's your problem with libraries marking their functions as constexpr then. The library says it's up to the caller to decide whether this function is constant evaluated. The problem was explained here: https://news.ycombinator.com/item?id=28895123 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.
pjmlp 5y ago
It can, check the C++ compiler Circle. https://www.circle-lang.org https://www.circle-lang.org Unfortunately it isn't a direction WG21 is willing to adopt.
- wtetzner 5y ago
  I just assumed the constexpr keyword was added to help the programmer ensure that what they were writing could be run at compile time.
nuerow 5y ago
> I will admit that when I first read about constexpr my first thought was 'why can't the compiler figure this out automatically?'. 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.
- dataflow 5y ago
  > 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. 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.
  - nuerow 5y ago
    > 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). 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.

rowanG077 5y ago

The compiler can figure it out. But that doesn't solve the problem constexpr was created for. Without constexpr compile time evaluation becomes very brittle. Constexpr is there to help the compiler and developer reach an understanding of the stuff that has to be evaluated at compile time.

atq2119 5y ago
The problem is that (especially library) code just becomes absolutely littered with constexpr, because realistically speaking, you do want everything that can be constexpr to actually be constexpr.
- rowanG077 5y ago
  Why is that a problem? I actually really like seeing if a library function can be cte'd.
  - dataflow 5y ago
    > Why is that a problem? 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 https://gcc.godbolt.org/z/bWzd4v6Y1
    - rowanG077 5y ago
      consteval says it MUST be constant evaluated not that it CAN be constant evaluated. That is very different. With consteval it's not up to the caller to make the decision of whether to run at compile-time or not, the caller must provide constexpr arguments. With just a constexpr annotation the caller can decide to run it either at compile-time or run-time. See this code: https://godbolt.org/z/oMWKcWW5e https://godbolt.org/z/oMWKcWW5e
      - dataflow 5y ago
        Like I said: >> [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 https://gcc.godbolt.org/z/bWzd4v6Y1 Note I didn't claim this was their only difference.
        rowanG077 5y ago
        I don't see what's your problem with libraries marking their functions as constexpr then. The library says it's up to the caller to decide whether this function is constant evaluated. Precisely what you wanted. If libraries start marking their function as consteval. Now that would be a problem.
        dataflow 5y ago
        > I don't see what's your problem with libraries marking their functions as constexpr then. The library says it's up to the caller to decide whether this function is constant evaluated. The problem was explained here: https://news.ycombinator.com/item?id=28895123 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.

pjmlp 5y ago

It can, check the C++ compiler Circle. https://www.circle-lang.org https://www.circle-lang.org Unfortunately it isn't a direction WG21 is willing to adopt.

wtetzner 5y ago
I just assumed the constexpr keyword was added to help the programmer ensure that what they were writing could be run at compile time.

nuerow 5y ago

> I will admit that when I first read about constexpr my first thought was 'why can't the compiler figure this out automatically?'. 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.

dataflow 5y ago
> 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. 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.
- nuerow 5y ago
  > 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). 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.