Thread

C++26: Trivial infinite loops are no longer undefined behaviour

173 points · 290 comments · ibobev

JoshTriplett · 1789746575 · focus · HN ↗
> When both conditions are met, the loop body is replaced with a call to std::this_thread::yield().
Insert screaming here.
An infinite loop, with no library calls whatsoever, gets a system call inserted. That's a horrible surprise waiting to happen.
The entire concept of the "forward progress guarantee" is broken. An infinite loop should compile to an infinite loop. Nothing more, nothing less.
1. ameliaquining · 1789747543 · focus · HN ↗
  I'm curious, what exactly do you imagine going wrong here?
  1. rfgplk · 1789750325 · focus · HN ↗
    The language is already littered with these "the compiler shall insert" and then a reference to the STANDARD LIBRARY FEATURE N.X. Which means if you're compiling in a freestanding environment half the time you'll get linker errors such as "couldn't find symbol whatever". And what's worse the compiler inserts a call to a function that is LITERALLY STD NAMESPACED. Meaning you have to provide that signature yourself. See how std vector is hardcoded into compare/meta and I can't remember what else.
    This then forces developers to create undefined behaviour because according to the standard you can't namespace std your own functions even though it's required to get it to work.
    mitxela · 1789778085 · focus · HN ↗
    Sounds like a compiler bug that a standard feature implementable in freestanding doesn't work in freestanding.

Unofficial Hacker News client; not affiliated with Y Combinator.