RangeFrom should have an infinite size_hint

[scottmcm]

Before,

(0..).take(4).size_hint() == (0,Some(4))

With this change,

(0..).take(4).size_hint() == (4,Some(4))

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[ollie27]

RangeFrom:

Note: Currently, no overflow checking is done for the iterator implementation; if you use an integer range and the integer overflows, it might panic in debug mode or create an endless loop in release mode. This overflow behavior might change in the future.

I'm not sure we can say RangeFrom is really infinite with it's current implementation. With debug assertions enabled for example 0u8.. certainly isn't: #25708.

[scottmcm]

RangeFrom::next() never returns None, so it's "infinite".

panic! doesn't impact size_hint. For example, this passes:

let it = (-5..5).map(|x| 100 / x);assert_eq!(it.size_hint(),(10,Some(10)));

Even though iterating it will panic with "attempt to divide by zero" before returning 10 items.

A lower-bound of 0 is inappropriate with other adapters. I mentioned Take above. it.zip(0..) is another example -- that should have the same size_hint as it, which will only happen with RangeFrom::size_hint returning (usize::MAX, None).

[alexcrichton]

Ah yeah I think what @scottmcm said makes sense to me, especially because it's impossible to return None from these iterators. Thanks for the PR @scottmcm!

@bors: r+

[bors]

📌 Commit 265dce6 has been approved by alexcrichton

[ollie27]

Infinite iterators can have any lower bound so I don't think this line should have been added.

[ollie27]

Well I guess if RangeFrom ever gets a sane Iterator implementation this can be changed if needed.

[Mark-Simulacrum]

@bors rollup