5 ms·

The problem is that (especially library) code just becomes absolutely littered with constexpr, because realistically speaking, you do want everything that can b

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.
        rowanG077 5y ago
        You are going in circles... 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.
        dataflow 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.
        rowanG077 5y ago
        You are going in circles... 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.
        dataflow 5y ago