Exactly. Optimisations like this are a least common denominator problem, in that to some extent you have to cater for the worst runtime that your code is likely

Exactly. Optimisations like this are a least common denominator problem, in that to some extent you have to cater for the worst runtime that your code is likely to run on, even if other runtimes would do a better job without needing your help. As for the premature optimisation comment made by grannyg00se above, I am very wary of applying that logic here. We're talking about an obvious potential inefficiency that is actively being introduced if we choose to write a for-loop in a certain way that most of us are used to. As the original article demonstrates, there are many other ways we could write that loop without that inefficiency, so I think this is more a case of not introducing unnecessary overhead when there's no good reason for it. (We don't know it's going to be an inefficiency in practice, but assuming it won't be is essentially a Sufficiently Smart Compiler argument.)