Fix Int#downto with unsigned int going down to 0.

[gmarcais]

See issue #6669. When using unsigned integers with the downto method, and the to is equal to 0, the code is an endless loop:

3.downto(0) { |i| p i } # Prints 3, 2, 1, 0
3_u16.downto(0) { |i| p i } # Endless loop printing 3_u16, 2_u16, 1_u16, 0_u16, 65535_u16, ...

Both version of the downto method (with and without a block) are fixed by this patch.

[Sija]

Wrong indent.

[asterite]

What happens with 3_u16.downto(4_u16).to_a?

[gmarcais]

Hum. 3_u16.downto(4_u16).to_a does not work. Let me fix the case when it goes up to return an "empty" iterator.

[asterite]

@gmarcais You can probably do something like @done = true unless @from >= @to in the iterator's constructor.

(edit: changed from false to true)

[gmarcais]

I modified to @done = !(@from >= @to) in the constructor and in rewind.

[Sija]

@gmarcais Would be good to add a spec for a case mentioned by @asterite.

[gmarcais]

Added spec cases for .to_a.

[straight-shoota]

Please also fix #upto at into max (see #6669 (comment))

[gmarcais]

I don't get that error. It does not seem to have anything to do with the current patch:

 1) Semantic: macro allows declaring class with macro expression
       fork: Cannot allocate memory (Errno)

I changed the comment on the patch. Does this have anything to do with it? (Seems unlikely, but I ask nevertheless). Any idea what went wrong?

[Sija]

It does not seem to have anything to do with the current patch

That's correct, nothing to worry about.

[straight-shoota]

@gmarcais Why close?

[gmarcais]

I did not do that. Not sure what happened. Can it be reopened (I personally cannot apparently)? I was still considering fixing the step method and related.

[gmarcais]

I added a version of the step method that does not overflow as well.

[asterite]

@gmarcais You probably need to rebase your branch against master

[gmarcais]

@asterite Yes, I rebased and added the step method. That allowed me to reopen the issue.

I am not yet convinced about my implementation because of the following issue.

The step function is possibly a mess of many different types: self, to, by. They may all be different types. Say self is an Int32 equal to Int32::MAX-2 and to is a UInt32 equal to UInt32::MAX/2 + 2 (which is higher than Int32::MAX), what should the method do? Yield Int32 values up to Int32::MAX? Yield UInt32 values up to to?

One can imagine crazier combination: self is an Int32, by is a Float and to is a Double larger than Int32::MAX.

Should there be some type restrictions?

[straight-shoota]

I don't think it would hurt to just restrict the arguments to the same type as self.

[asterite]

Yeah, it's a crazy combination. Right now you can even do:

1.step(to: 3.5, by: 0.5) do |i|
  puts i # => 1.0, 1.5, ...
end

I'm not sure restricting the types is the way to go, but we could try it.

But I'd try to not involve step in this PR because it will make it harder to decide when and how to merge this. Let's focus on downto, and we can fix upto and step in separate PRs (or, well, upto is probably fine in this PR).

[RX14]

I'd cast to the self type using self.class.new(to), like like the lhs type rule for operators.

But yes, another PR please.

[gmarcais]

OK, I reverted the step method changes. The current PR only contains the upto and downto methods. I'll create a new PR for step.