The while loop is nothing more than a check condition, same as an If statement.
I’d say the fact you have to ask about whether this works, and works reliably means you might want to implement your code in way that you KNOW its reliable and works as expected
I know exactly what you’re asking and often set a simple boolean for “bailedEarly” instead of relying on checking the index > ubound or whatever
[code]
dim i as Integer
dim bailed as boolean
for i = 0 to 10
if i = 5 then
bailed = true
exit for i
end if
next
if bailed then
// do whatever to handled bailing out early
else
// whatever to handle NOT having bailed out early
end if[/code]
Now, and I’m sure when we get a chance to ask Joe or when he comments, what you’ll find is that the current mechanism is unlikely to change and the behavior is likely to be reliable. It could break code to just change how for loops behave
However you COULD rewrite your for loop as
dim i as integer = 0
do until i > 10
if i = 5 then
exit
end if
listbox1.addrow str(i)
i = i + 1
loopit will behave the same as the for loop
I doubt anyone would suggest that the variable i is unusable after the loop with the DO version
I actually didn’t have to ask, but a co-worker made me 
I’ve both seen and used similar conditions in the C language.
C is a different beast of course, but never had any fears there, not sure why we should have a fear in Xojo.
99% of all of my code, I define the loop variable in the for loop because I hate dirtying the namespace uselessly and like my variables defined close to their use. Just in one condition today I found it useful.
this got me curious…
var i:Int=99
for i in(0...10) {
println("Inside:\\(i)")
}
println("Outside:\\(i)")Guess what prints for OUTSIDE
[quote=193944:@Dave S]this got me curious…
var i:Int=99
for i in(0...10) {
println("Inside:\\(i)")
}
println("Outside:\\(i)")Guess what prints for OUTSIDE[/quote]
Don’t know for sure, but by reading it, I’d guess 99. I think swift defines i for the context of the for loop itself. Just because one language does something different doesn’t mean you shouldn’t do it in Xojo. Don’t program for the lowest common denominator, program for the language you are working in.
[quote=193943:@Jeremy Cowgar]I actually didn’t have to ask, but a co-worker made me I’ve both seen and used similar conditions in the C language.
C is a different beast of course, but never had any fears there, not sure why we should have a fear in Xojo.
99% of all of my code, I define the loop variable in the for loop because I hate dirtying the namespace uselessly and like my variables defined close to their use. Just in one condition today I found it useful.[/quote]
Ditto to much of this
I’ve done this as well - it has uses sometimes
I think you can rely on the behavior
My point wasn’t that XOJO does it one way, and SWIFT does it another…
Well actually it was… because if you get youself into the mind set that all languages will treat for/next the same… you are in for trouble
ok… this has sunk to a Religion/Politics level debate…
[quote=193947:@Dave S]My point wasn’t that XOJO does it one way, and SWIFT does it another…
Well actually it was… because if you get youself into the mind set that all languages will treat for/next the same… you are in for trouble[/quote]
Yes. You can see some of my Xojo code that I do like C 
I wrap a lot of my compares and returns in parens. That being said, I switch language contexts pretty easily, for the most part. However, your point is valid. Language context switching is important, especially if you program in multiple languages on a daily basis.
My personal favourite (yes its legal)
[code] dim i as integer
do until i > 10
i = i + 1
loop until i > 10
[/code]
Didn’t mean for that. Original question was if the loop variable can be trusted after exiting the loop, but it turned to a debate of if that is good or bad. I do like debating these topics on a technical level with technical points.
While it is reliable and I have used it myself, it is programming by side effect. You’re counting on a particular implementation of the loop construct. Should that implementation ever change…
My Point exactly! 
Read Code Complete I and II by Steve O’Donnell. These practices have been metricized scientifically, and using loop counters as working variables promotes bugs. Not only did I learn a lot by reading the books, it also made it obvious that there are many very smart people that study this for a living. It (slowly) dawned on me that I shouldn’t be arguing with proven and validated sciences of coding.
Look, just the fact that it’s HARDLY obvious if a loop counter (at least in BASIC) is incremented in the final test should establish that loop counters should not be counted as reliable outside the loop. Their use is within the loop, nothing more. S is absolutely correct.
Have to agree with Garth here. Though I’m sure I’ve been guilty of it at some point, I try to stay away from using a variable for more then one clear purpose. Your loop counter should be a loop counter and nothing more.
In my example, the variable is not being used for multiple purposes. It is only being used as a loop index, but is left around to be used as a loop index multiple times within the exact same loop. I agree whole heartedly using a variable for multiple purposes is a bad thing and would never do something like that.
https://forum.xojo.com/23279-for-i-0-to-10-count-on-i-after-for-has-exited/p1#p193937
Since the variable has been initialized before the loop, it can be trusted to exist. Trusting its value is another thing, but I do not see why Xojo should break something that has existed for so long.
If you just want to make sure the loop has completed, it makes no much difference if i equals 10 or 11. The fact that it increases one after the loop is not much more than an interesting curiosity. After all, it cannot be much worse than ubound being one based for arrays that are zero based 
I’ve read Code Complete in the past, I thought Code Complete 2 though was just a 2nd edition… Not having ever picked up Code Complete II, do you find there is a lot of new, good information in the 2nd edition vs. the first?
By curiosity, I just ran the loop in GWBasic. The result after the loop is i = 11. Seems Xojo is in a VERY long tradition here. I would be extremely surprised that changed now. Jeremy, you are probably safe for a long time 
To solve almost all of this debate, all it would take is a documentation entry detailing the result of the loop counter. Then it wouldn’t be undocumented and one wouldn’t be relying on a particular implementation. For example, we all rely on a particular implementation detail. if True then… We assume that if the condition is true, then something happens. The only reason we rely on that is because it is documented
The documentation already documents the i = 11 case by example, just not definition.
P.S. Just checked the GW-Basic docs, it actually documents this behavior in both counting up and down. Can’t believe I have a manual laying around, it is the Second Edition (May 1982) Version 1.10
I actually only read Code Complete Second Edition. (You are right about the editions, it’s just the presentation that makes it seem it’s Code Complete 2.)
Here’s a resource about the differences. This isn’t in the Second Edition itself. http://cc2e.com/Default.aspx?hid=337