Thread

1. 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. ozgrakkurt · 1789748658 · focus · HN ↗

      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.

      1. muvlon · 1789750765 · focus · HN ↗

         It's not even about optimizing some big tech codebase by 0.5%. The progress guarantees in particular are in place s.t. Nvidia can choose a certain implementation strategy in Cuda C++ that has "surprising" consequences for users (one thread getting stuck in an infinite loop that never yields can livelock its entire warp) but still get to claim "full C++ standards compliance".

         1. mschuetz · 1789792372 · focus · HN ↗

            I don't see the issue. Just let wrong code do wrong things But let it do the expected wrong thing, rather than changing the code to something unexpected.

            1. cryptonector · 1789793819 · focus · HN ↗

               "No." <-- the C++ committee.
            2. Dylan16807 · 1789854272 · focus · HN ↗

               Good luck defining "expected" for most of the more complex cases.

               1. mschuetz · 1789895910 · focus · HN ↗

                  Seems trivial to me for infinite loops. Nothing special to specify here, they're already specced by the definition of loops.

Unofficial Hacker News client; not affiliated with Y Combinator.