Thanks, I understand. Final set of questions, I hope: if the compiler is not allowed to do these optimizations even in the const case due to potential side effects, why does SonarLint propose these changes then? One reason might be “because SonarLint knows that map::at() does not have side effects, and moving the stop condition out of the loop will not change runtime behavior” - is that correct?
I also understand the reasoning for your answer to my second question, but find it at odds with the definition of the rule, which says it will flag stop conditions using a method call. First, it does not do that here. Second, the reason why it’s not flagged sounds weird to me: I understand that you are saying that SonarLint knows that map.operator[]() has side effects - but wouldn’t that be an extra-strong reason to flag this stop conditions? After all, the rule aims to avoid stop conditions “being difficult to understand and maintain”, and that is much more true in the second case than in the first.
Either way, I think the wording of the rule should be modified to match the implementation, and possibly also to further clarify its intent (especially in terms of breaking or not breaking run-time behavior, and regarding side effects).