explicitly show how iterating over .. fails

[matthew-piziak]

I've also removed the main() wrapper, which I believe is extraneous.
LMK if that's incorrect.

[matthew-piziak]

r? @steveklabnik

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[strega-nil]

It's technically an IntoIterator implementation that's the problem.

[matthew-piziak]

@ubsan I thought that too, but the error threw me off.

main.rs:15:5: 17:6 error: the trait bound `std::ops::RangeFull: std::iter::Iterator` is not satisfied [E0277]
main.rs:15     for i in .. {
               ^
main.rs:15:5: 17:6 help: run `rustc --explain E0277` to see a detailed explanation
main.rs:15:5: 17:6 note: `std::ops::RangeFull` is not an iterator; maybe try calling `.iter()` or a similar method
main.rs:15:5: 17:6 note: required by `std::iter::IntoIterator::into_iter`

[strega-nil]

@matthew-piziak weird implementation thing. It's looking for IntoIter through Iterator

[matthew-piziak]

@ubsan Could you elaborate on that? I think I'm missing a piece of the puzzle. I know that IntoIterator is supposed to be the trait that governs for loops, but the difference between Range and RangeFull in the source is that only Range has an Iterator implementation. Do you think saying "This errors because .. has no Iterator impl" is disingenuous? What would be more accurate?

[strega-nil]

@matthew-piziak Okay, so.

for x in y {
    ...
}

becomes

let __tmp = IntoIterator::into_iter(y);
while let Some(x) = __tmp.next() {
    ...
}

the only thing that is necessarily an Iterator is __tmp, but that's guaranteed by the IntoIterator impl; that's not what the error's about.

However, the question is, how does rustc find an IntoIterator implementation? It first checks typeof(y) for an implementation of IntoIterator. It then looks for any impl<T: ...> IntoIterator for T { ... }. It then, for each of these blanket implementations, checks typeof(y) for an implementation of the given traits. Since there's an impl<T: Iterator> IntoIterator for T { ... }, it checks typeof(y) for an Iterator impl after checking for an IntoIterator impl, but there is none. Since Iterator was the last trait checked for, rustc errors, saying it was unable to find the Iterator implementation, even though it was looking for an IntoIterator implementation.

Sorry if this is confusing, I'm pretty tired.

[matthew-piziak]

Sorry if this is confusing, I'm pretty tired.

Not at all. Thank you so much for the explanation. I get how it works now. :)

[steveklabnik]

So, usually rather than commenting the code out, we put things in its own example marked with ignore. And in general, these feel like three separate examples to me. Could you maybe split them up, and put a little sentence between them explaining it?

So for example:

/// The `..` syntax is a `RangeFull`:
///
/// ```
/// assert_eq!((..), std::ops::RangeFull);
/// ```
///
/// It does not have an `IntoIterator` implementation, so you can't use it in a
/// `for` loop directly. This won't compile:
///
/// ```ignore
/// for i in .. {
///    // ...
/// }
/// ```

Something like that? What do you think?

[matthew-piziak]

Yes! I'm thinking that's much better. Will impl. :)

[steveklabnik]

@bors: r+ rollup

[bors]

📌 Commit 469b7fd has been approved by steveklabnik