4 ms·

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 abs

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
      > Imagine updating a dependency or rewriting a function and suddenly your program is 10x slower. 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 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 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.
      - rowanG077 5y ago
        > [2] Notice that seeing consteval here tells you absolutely nothing: https://gcc.godbolt.org/z/bWzd4v6Y1 https://gcc.godbolt.org/z/bWzd4v6Y1 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); } Marking foo as constexpr makes it compile and compile time evaluate both foo and bar. > 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 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 At least try to the examples you are using to make your point. Because they in fact show that you are wrong...

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
    > Imagine updating a dependency or rewriting a function and suddenly your program is 10x slower. 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 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 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.
    - rowanG077 5y ago
      > [2] Notice that seeing consteval here tells you absolutely nothing: https://gcc.godbolt.org/z/bWzd4v6Y1 https://gcc.godbolt.org/z/bWzd4v6Y1 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); } Marking foo as constexpr makes it compile and compile time evaluate both foo and bar. > 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 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 At least try to the examples you are using to make your point. Because they in fact show that you are wrong...