Implement range syntax

[nrc]

Closes #19794

r? @aturon for the first patch
r? @nikomatsakis for the rest

[aturon]

Yay! Delighted to see this, @nick29581

[sfackler]

"is". Might want to mention "half open" in the type docs as well.

[sfackler]

Might as well implement ExactSizeIterator as well.

[sfackler]

Do we want to do this or stop at the maximum value?

[sfackler]

Now that I think about it, does it even make sense for this to implement Iterator?

[nrc]

I had a bit of a discussion about this on IRC and the consensus was yes it makes sense (although basically only to use take on) and that looping forever was probably what you would expect, rather than stopping at the max int (it's also more efficient).

[aturon]

Note, we've long had this iterator: http://static.rust-lang.org/doc/master/std/iter/fn.count.html

This notation will just serve to make it a bit more convenient. I'm hoping that we can drop many of the bare fns in std::iter in favor of this notation.

[huonw]

uint doesn't always work for u64/i64 on 32-bit platforms.

[nrc]

I guess T should be u64 for u64/i64 and we require T=uint for to implement iterator. We need the snapshot for that, but hopefully it can happen before this lands

[huonw]

Shouldn't this be signed?

[nrc]

Urgh, yes, kinda, the problem is that then it can overflow. I think I should just comment better that this is the magnitude of the difference and that we assume a > b (I could debug_assert that)

[huonw]

Can these be derived?

[nrc]

IDK - is deriving clever enough to add bounds on generics like this?

[sfackler]

Yep

[huonw]

This test doesn't detect the iteration being shorter than expected (or not occur at all), could be something like

let mut r = Range { ... };
let mut i = 0;
for ri in r {
    assert!(...);
    assert!(...);
    i += 1;
}
assert_eq!(i, 8);

[aturon]

@nick29581 left some comments -- though possibly on a stale commit? In any case, I'm basically fine with landing this as-is in terms of naming and placement of the Countable trait -- I have some thoughts but can move things around during stabilization.

[nrc]

@aturon I like the Step idea, but I prefer that we use an associated type for the result of steps_left, otherwise you get into overflow territory. I think we can use an equality constraint on the associated type <T=uint> to make this work for the size hint (i.e., you only get an Iterator implementation when it is safe to give a size hint, with better trait matching in the future, we could do better and always get an Iterator impl, but only give a size hint if it is safe).

[aturon]

@nick29581 What about making it return Option<uint>? Its sole purpose is for the size hint, right?

[nrc]

@aturon it is for now, yes (if the trait is meant to be more generally useful, then I guess it should handle more here, but perhaps we should ere on the side of YAGNI here.). Does size_hint need to be fast? I.e., is it worth trying to avoid the branch? If not, then Option seems fine for now.

[aturon]

Usually size_hint is called ahead of fully iterating, so the branch
shouldn't matter much -- but in any case you should be able to use
#[inline].

I also agree that YAGNI seems best here. We recently axed a lot of the
numerics traits to punt general numerics treatments to the Cargoverse --
partly because there are so many ways to do it. Staying focused on the
main use case of iterating over range syntax seems best.

On Mon, Dec 15, 2014 at 3:48 PM, Nick Cameron notifications@github.com
wrote:

@aturon https://github.com/aturon it is for now, yes (if the trait is
meant to be more generally useful, then I guess it should handle more here,
but perhaps we should ere on the side of YAGNI here.). Does size_hint need
to be fast? I.e., is it worth trying to avoid the branch? If not, then
Option seems fine for now.

—
Reply to this email directly or view it on GitHub
#19858 (comment).

[sinistersnare]

Is something like the following in this PR? Just a thought I had a few minutes ago.

for i in (0..) {
    println!("infinite loop! i: {}", i);
}

[nrc]

@sinistersnare yes, that will work, you don't even need the brackets around the range

[nikomatsakis]

Exciting.

[nikomatsakis]

So this looks reasonable, though I'm wondering if we can just desugar these expressions in the front-end and save ourselves a lot of weird bugs down the line. This seems like a classic case.

[nikomatsakis]

r+ modulo comments and in particular the question about using a common supertype, though perhaps we can discuss whether to desugar etc on IRC

[quantheory]

s/negtive/negative/

[quantheory]

s/tow/two/

[nrc]

r=aturon,nikomatsakis

[bors]

saw approval from aturon
at nrc@e82215d