I grilled an LLM for a bit to see if it could justify the old forward progress rule. The only thing I got that passed the smell test was that it’s useful for the optimizer to be able to optimize:

    messy_pure_computation();
    some_atomic.store(1, relaxed);

I admit I’m unconvinced that this is particularly useful.

(I got many other ideas that did not pass my personal smell test.)

I guess given that it was UB before, the compiler was already allowed to put a system call here if it wanted for some reason

But the compilers have to optimize the crap code in big tech codebases by 0.5%, it saves a lot of money.

Also performance doesn't matter that much and developer time is more important btw, keep using react.

Yeah, this is almost the worst way they could choose to 'fix' the problem.

Yeah, I don't get it either. Like if I wanted to call std::thread::yield() inside an infinite loop, I could, you know, just do that myself?

An obvious question (that TFA does not address) is, why is the forward-progress guarantee needed? Since that is the ostensible justification for this new invisible behavior.

> An infinite loop should compile to an infinite loop.

I think that a compiler option should control this. It can be a nice optimization, but the programmer should be able to opt out.

I'm curious, what exactly do you imagine going wrong here?

Forward progress guarantee is what allows for conversion between recursion and iteration for performance optimization. Otherwise these have different characteristics (recursion blows the stack, a loop hangs).

I don't understand your problem. Did you expect your C++ program to get uninterrupted access to the computer? What progression do you think isn't happening there?

I think you are misinterpreting that. That phrase unambiguously says the loop is preserved on the final binary.