I know it’s kind of annoying to ask a question only to have the responses not be an answer to your question but deconstructions of your question =) But it kind of has to be in thsi case. In the computer world, we are ALWAYS relying on someone elses work, whether it be foundation classes or even the language you are writing in. It is mission-critical to remember that and to isolate yourself from what someone else thinks or believes about “what should be”.
Perhaps the language implementation will change, or perhaps it won’t - but that’s beyond the real point - don’t mix tasks. Or as Tim said, don’t “program by side effect”. Be obvious. Be boring. Be right.
In this case it’s two different abstractions - one is the act of cycling and the other is the act of making a calculation. Merging the tasks seems sexy but it really isn’t productive. It really shouldn’t help the compiler, and it’s hiding the real act -the calculation. The cycling passes away but the calculation is permanent/ongoing. It’s not immediately obvious but it’s not intuitive nor logical. Getting into the practice of separating the acts improves your logical faculties in the long term. That’s what I’ve found is the real payoff of “playing by the rules” - very similar to finding out after you grow up that your parents were right after all. =)
And sorry for a lecture. =( But I really appreciate these types of disciplines, it’s paid off.
[quote=193865:@Jeremy Cowgar]Can we count on the current behavior of the for loop? For example:
dim i as Integer
for i = 0 to 10
if i = 5 then
exit for i
end if
next
Print Str(i) // prints 5
Also, when not exiting early:
dim i as Integer
for i = 0 to 10
// do something
next
Print Str(i) // prints 11, i.e. ran until i incremented > 10
It is not documented as to what i should be in these cases, but the docs at least rely on this to be the case in one example. Can we trust this will always be the case in our code also?[/quote]
Yes, this is the correct behavior and not going to changed. However, as mentioned by the other posters, it might not be the best way to approach the problem.
OK, so the reason for not using it is no longer because the implementation might change. Cool! The other objection was using a single variable for multiple purposes which I’d never do, that’s silly of course.