3 ms·

>You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible")... This feels like a lot of line noise for those rare-until-you-hit-them bugs. Ju

>You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible")... This feels like a lot of line noise for those rare-until-you-hit-them bugs. Just capping a loop with a fixed iteration size deserves a comment as to the rationale. Do you do it everywhere? Just IO? The idea has merit, but in practice, I am not sure where I would implement it. Plus, there would always be the temptation to remove that do-nothing code.

tmtvl 4y ago
> This feels like a lot of line noise for those rare-until-you-hit-them bugs. Yeah, but if doing so can eliminate an entire class of bugs... ...you know something? I think I'm starting to see where those Rust guys are coming from.
oneeyedpigeon 4y ago
> Plus, there would always be the temptation to remove that do-nothing code. It's not 'do-nothing' code, though. Isn't the temptation just the same as the temptation to remove 'do-nothing' exception handling or 'do-nothing' unit tests?
vidarh 4y ago
If it's much "do nothing" code to remove, perhaps it'd be better to move to a more expressive language. E.g. for Ruby at least, block arguments means it's trivial to do this: def at_most(num) num.times { yield } raise "Should never get here" # or "binding.irb"/"binding.pry" to drop you into a repl, perhaps contingent on a command line flag. end and do: at_most(5) do .. logic end If the number isn't obviously absurdly high, I agree it'd be worth documenting why the precise number was chosen, but then it might be worth documenting why as an indication of why you thought an infinite loop was appropriate anyway.
- Groxx 4y ago
  Yep. In essentially every language there's a reasonably efficient way to do it in one or two lines at most. It's really not much noise, and it serves as (mechanically checked!) documentation of the expected size of a loop. In some ways that's an improvement, since it's just a loopy assert.
Groxx 4y ago
As a counter-argument: why are we generally ok with allowing things to be infinite when they're expected to be finite? Precise bounds are obviously best, but sometimes it's not efficiently calculable or not worth the effort - don't choose the literal worst possible value there (infinity), pick something that'll stop itself when it goes insane. And no, it's a tool. Use it where it makes sense.

tmtvl 4y ago

> This feels like a lot of line noise for those rare-until-you-hit-them bugs. Yeah, but if doing so can eliminate an entire class of bugs... ...you know something? I think I'm starting to see where those Rust guys are coming from.

oneeyedpigeon 4y ago

> Plus, there would always be the temptation to remove that do-nothing code. It's not 'do-nothing' code, though. Isn't the temptation just the same as the temptation to remove 'do-nothing' exception handling or 'do-nothing' unit tests?

vidarh 4y ago

If it's much "do nothing" code to remove, perhaps it'd be better to move to a more expressive language. E.g. for Ruby at least, block arguments means it's trivial to do this: def at_most(num) num.times { yield } raise "Should never get here" # or "binding.irb"/"binding.pry" to drop you into a repl, perhaps contingent on a command line flag. end and do: at_most(5) do .. logic end If the number isn't obviously absurdly high, I agree it'd be worth documenting why the precise number was chosen, but then it might be worth documenting why as an indication of why you thought an infinite loop was appropriate anyway.

Groxx 4y ago
Yep. In essentially every language there's a reasonably efficient way to do it in one or two lines at most. It's really not much noise, and it serves as (mechanically checked!) documentation of the expected size of a loop. In some ways that's an improvement, since it's just a loopy assert.

Groxx 4y ago

As a counter-argument: why are we generally ok with allowing things to be infinite when they're expected to be finite? Precise bounds are obviously best, but sometimes it's not efficiently calculable or not worth the effort - don't choose the literal worst possible value there (infinity), pick something that'll stop itself when it goes insane. And no, it's a tool. Use it where it makes sense.