It really isn't that unclear, to me at least. If it's unclear to other programmers, I think that's only because gotos have fallen so far out of fashion that the

It really isn't that unclear, to me at least. If it's unclear to other programmers, I think that's only because gotos have fallen so far out of fashion that they look alien now. That's really a shame, because there are cases for the elegant use of goto, and I think the retry() code above is one of them. You argued earlier that there was no point in making this optimization in the first place, since it probably wasn't contributing a significant delay in the application (which I disagree with on the grounds that we don't know what retry() might be used for), but now you're saying that it shouldn't be done this way because the compiler might later do a better job of optimizing a standard loop. As others have pointed out, there are some good reasons not to expect PHP's bytecode runtime to match the optimizations of other software compilers. Without knowing in advance exactly how many times the function call embedded in retry() will be repeated -- which seems pretty unlikely -- there's no good way for the compiler to unroll the loop more efficiently than has already been done here with the straightforward application of a goto. Sure, in general, don't be too clever. (Rather, "don't be cruel to future programmers".) I agree. But, I think there's a far greater danger of programmers blindly following guidelines like "don't use goto" without consideration. So while there probably isn't a good argument for writing this function this way, there also isn't a good argument against it -- which is what makes all of the discussion around it so funny.