News for hackers. Stuff that matters.
Re:Proposal to add constexpr to C [pdf] by rowanG077 on Monday October 18, 2021 @09:21AM (#28905165)
> [2] Notice that seeing consteval here tells you absolutely nothing: 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

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...
Re:Proposal to add constexpr to C [pdf] by dataflow on Monday October 18, 2021 @09:55AM (#28905467)
The examples are not wrong, you're just not understanding them.

> 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.

Re:Proposal to add constexpr to C [pdf] by rowanG077 on Monday October 18, 2021 @10:33AM (#28905818)
The code doesn't compile, so it did in fact stop the author from calling a non-constexpr function from a constexpr function. You can't meaningfully semantically talk about code that doesn't compile.
Re:Proposal to add constexpr to C [pdf] by dataflow on Monday October 18, 2021 @01:07PM (#28907831)
> You can't meaningfully semantically talk about code that doesn't compile.

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.