Skip to content

std::iter: Introduce .by_ref() adaptor #9634

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

Merged
merged 1 commit into from
Oct 17, 2013
Merged

std::iter: Introduce .by_ref() adaptor #9634

merged 1 commit into from
Oct 17, 2013

Conversation

bluss
Copy link
Member

@bluss bluss commented Sep 30, 2013

std::iter: Introduce .by_ref() adaptor

Creates a wrapper around a mutable reference to the iterator.

This is useful to allow applying iterator adaptors while still
retaining ownership of the original iterator value.

Example::

let mut xs = range(0, 10);
// sum the first five values
let partial_sum = xs.by_ref().take(5).fold(0, |a, b| a + b);
assert!(partial_sum == 10);
// xs.next() is now `5`
assert!(xs.next() == Some(5));

This adaptor requires the user to have good understanding of
iterators or what a particular adaptor does. There could be some
pitfalls here with the iterator protocol, it's mostly the same issues
as other places regarding what happens after the iterator
returns None for the first time.

There could also be other ways to achieve the same thing, for
example Implementing iterator on &mut T itself:
impl <T: Iterator<..>> Iterator for &mut T but that would only
lead to confusion I think.

Creates a wrapper around a mutable reference to the iterator.

This is useful to allow applying iterator adaptors while still
retaining ownership of the original iterator value.

Example::

   let mut xs = range(0, 10);
   // sum the first five values
   let partial_sum = xs.by_ref().take(5).fold(0, |a, b| a + b);
   assert!(partial_sum == 10);
   // xs.next() is now `5`
   assert!(xs.next() == Some(5));
@bluss
Copy link
Member Author

bluss commented Sep 30, 2013

Needs some scrutiny of potential pitfalls and compatibility with overall iterator design, cc @thestinger ! :-)

@bluss
Copy link
Member Author

bluss commented Sep 30, 2013

.size_hint implementation is blocked by issue #9629 (There is a FIXME for this in the code)

bors added a commit that referenced this pull request Oct 17, 2013
std::iter: Introduce .by_ref() adaptor

Creates a wrapper around a mutable reference to the iterator.

This is useful to allow applying iterator adaptors while still
retaining ownership of the original iterator value.

Example::

    let mut xs = range(0, 10);
    // sum the first five values
    let partial_sum = xs.by_ref().take(5).fold(0, |a, b| a + b);
    assert!(partial_sum == 10);
    // xs.next() is now `5`
    assert!(xs.next() == Some(5));

---

This adaptor requires the user to have good understanding of
iterators or what a particular adaptor does. There could be some
pitfalls here with the iterator protocol, it's mostly the same issues
as other places regarding what happens after the iterator
returns None for the first time.

There could also be other ways to achieve the same thing, for
example Implementing iterator on `&mut T` itself:
`impl <T: Iterator<..>> Iterator for &mut T`  but that would only
lead to confusion I think.
@bors bors closed this Oct 17, 2013
@bors bors merged commit 8163cb5 into rust-lang:master Oct 17, 2013
@bluss bluss deleted the by-ref-iter branch October 17, 2013 06:23
flip1995 pushed a commit to flip1995/rust that referenced this pull request Oct 20, 2022
…=Manishearth

Update Applicability of `redundant_allocation` lint from `MachineApplicable` to `MaybeIncorrect`

This changes `redundant_allocation` lint from MachineApplicable to MaybeIncorrect

```
changelog: [`redundant_allocation]: Change Applicability from MachineApplicable to MaybeIncorrect

```

fixes rust-lang#6243

---
changelog: [`redundant_allocation`]: Change Applicability from MachineApplicable to MaybeIncorrect
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants