Update loop

[Willamin]

This adds an optional argument to the top level loop method. Sometimes it makes sense to start iterating at a different number than 0.

[oprypin]

Please make the commit summary more descriptive.

Note: I am not voting for or against this change, just checking implementation.

[oprypin]

This should have a better name, like start.
Could utilize external names

[asterite]

Even though this is correct, maybe it's time to remove the argument to loop. It's not intuitive, it's Int32 by default, and it can overflow.

I'd vote to remove it.

[Willamin]

If loop lacked the block argument, would you suggest people create their own counters?
Something like this?

my_counter = 0
loop do
  puts my_counter
end

[asterite]

Yes, that's what you had to do before. Well, almost, you'd also increment the counter ;-)

[Willamin]

Oh yes, updating the counter inside the loop 😄

[bararchy]

I love the counter in loop, make it Int128 and were all OK :)

[Sija]

@asterite I'd rather add a NOTE regarding possible overflow, since it's rather common flow to use a counter inside of a loop. Also, couldn't we change it to UInt32/64?

[asterite]

Imagine one day we raise on overflow. Then loop will always eventually raise. Doesn't sound good. Let's remove that block argument already :-)

[asterite]

Again, we can add a note. Someone doesn't read it and they have a loop in a server:

loop do
  # accept connection
end

if we ever introduce raise on overflow, that will eventually raise. Why not make it explicit and use a counter, instead of loop having a variable? I can't remember who had the idea to introduce a counter... maybe me? If so, I regret it and I'd like to remove it.

[bcardiff]

For iterating other indices Range can be used. I agree we can remove loop (and would love to see raise on overflow :-) )

[Willamin]

Could we follow the example of each and each_with_index? Have a loop and a loop_with_index?

[Willamin]

We can't iterate infinitely over a Range, though

[bcardiff]

Ref #1407

[Willamin]

I think it would be fine to keep the iteration, especially since it gets optimized out when unused. If we ever introduce a raise on overflow, it would be easy to provide backwards compatibility by having the definition of loop rescue the exception. However, because Crystal isn't 1.0.0, I don't think backwards compatibility is all that necessary.

[bararchy]

Can we do

loop do 
 # no counter used
end

loop do |c|
  puts c
end

[Willamin]

Yes, that's what happens currently. If you compile with the --release flag and don't use the counter, the counter gets optimized out.

[RX14]

I can't really see any way to make this counter make sense after we add overflow detection, so I'm fine for removing it.

[straight-shoota]

Without a counter, there is however little benefit for loop over while true... It's just the block scope.

[bararchy]

@straight-shoota the block scope is handy, if you want work being done inside the loop but don't want the work to leak outside

[RX14]

@straight-shoota I use loop do instead of while true because it's more descriptive. There don't need to be a concrete technical benefit, loop do is wirth it just for the naming.