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.

[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 [email protected]
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/