Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace the current for protocol with external iterators #6997

Closed
thestinger opened this issue Jun 7, 2013 · 6 comments
Closed

Replace the current for protocol with external iterators #6997

thestinger opened this issue Jun 7, 2013 · 6 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@thestinger
Copy link
Contributor

The std::iterator::Iterator trait will need a lang item and Iterator implementations on functions will likely have to be forbidden to avoid ambiguity with internal iterators.

The body of the loop won't have to be a closure and return/break will never fail to work as expected.

See: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html

@thestinger
Copy link
Contributor Author

Nominating for the backwards compatible milestone. This will change the Iterator API by removing the need for the advance method.

@bblum
Copy link
Contributor

bblum commented Jun 7, 2013

Is there some reason you can't add an each method to the Iterator typeclass, and just write for iterator_value.each ... like today's syntax supports? Much less magic required.

@thestinger
Copy link
Contributor Author

@bblum: they do have that with an advance method, but beyond being ugly it doesn't take advantage of the fact that they don't need a closure and can always successfully break and return. The borrow/move checker is painful with our current loop.

@thestinger
Copy link
Contributor Author

Here's what it would do:

// for loop sugar
for xs.take_while(|x| *x < 5).zip(ys) |(x, y)| { return x + y; }

// equivalent low-calorie code, already compiling today
let mut it = xs.take_while(|x| *x < 5).zip(ys);
loop {
    match it.next() {
        Some((x, y)) => return x + y, // note that this will always return successfully
        None => break
    }
}

No more errors like this from return and break being lies:

foo.rs:17:24: 17:35 error: cannot borrow `(*foo)[]` as mutable more than once at a time
foo.rs:17             return Some(&mut foo[idx])
                                  ^~~~~~~~~~~
foo.rs:17:24: 17:35 note: second borrow of `(*foo)[]` as mutable occurs here
foo.rs:17             return Some(&mut foo[idx])
                                  ^~~~~~~~~~~
error: aborting due to previous error

They'll also compile much faster than closures and avoid the noisy .advance tacked on to every external iterator.

@graydon
Copy link
Contributor

graydon commented Aug 1, 2013

This was accepted for milestone 2. We're mid way through doing it now in eg. #8141 and #8184 .

@bblum
Copy link
Contributor

bblum commented Aug 3, 2013

👍 👍 👍 👍 👍

flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
fix `missing_panics_doc` not detecting `assert_eq!` and `assert_ne!`

fixes rust-lang#6997
changelog: `missing_panics_doc` detects `assert_eq!` and `assert_ne!`

---
searching for `assert_eq!` and `assert_ne!` in `FindPanicUnwrap`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

3 participants