An iteration statement whose controlling expression is not a constant expression, that
performs no input/output operations, does not access volatile objects, and performs no
synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate
“new Random().nextInt()” might perform I/O though so it could still be defined behavior. Or the compiler does not assume this assumption.
But an aggressive compiler could realize the loop would not terminate if x does not become 10 so x must be 10 because the loop can be assumed to terminate.
The compiler will optimize it anyway. /s
Not sure about the last one though. The other two are trivial to optimize away.
An infinite loop canot be ruled out in the last case, so a compiler couldn’t optimize this away without potentially changing the program behavior.
Infinite loops are often weird though. They could be seen as undefined behavior and the compiler may do whatever it feels like.
How could an infinite loop be considered UB?
Even though this isn’t C, but if we take from the C11 draft §6.8.5 point 6 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):
“new Random().nextInt()” might perform I/O though so it could still be defined behavior. Or the compiler does not assume this assumption.
But an aggressive compiler could realize the loop would not terminate if x does not become 10 so x must be 10 because the loop can be assumed to terminate.
You jest, but you aren’t wrong. At least if we are talking about C, C++ or Rust. https://godbolt.org/z/oPPfdfcf5
.NET compiler is weak when it comes to optimizing your code; I assume Go’s is as bad.
Technically yes… But I think he was more making the excuse for the gore “from the goresmith’s perspective.”
And I’m not sure if the compiler in any language would change a random check function… The others are a possibility.