Confusion with short lived lifetimed values that (on the surface) seem perfectly safe

Question

I'm having an issue writing a Lexical Analyzer in Rust where certain functions are starting to complain about simple snippets that would otherwise appear harmless. This is starting to become an annoyance as the error messages are not helping me pinpoint the cause of my problems and so this is the second time I'm reaching out on the same program in the same week (previous question here).

I have read the book, I've understood everything I could from it. I've also watched/read numerous other articles and videos discussing lifetimes (both explicit and implicit) and for the most part the concept behind borrowing and moving make perfect sense, except in cases like the following:

My lexer has a next function who's purpose is to peek ahead at the next character and return it.

struct Lexer<'a> {
    src: str::Chars<'a>,
    buf: String,
    // ... not important
}

impl<'a> Lexer<'a> {
    // ... not relevant

    // originally this -> Option<&char> which caused it's own slew of problems
    // that I thought dereferencing the character would solve.
    fn next(&self) -> Option<char> {
        let res = self.src.peekable().peek();
        // convert Option<&char> to Option<char>
        match res {
            Some(ref c) => Some(*c.clone()),
            None => None
        }
    }

    // ... not relevant
}

The error that I'm getting when doing this is:

error: borrowed value does not live long enough
       let res = self.src.peekable().peek();
                 ^~~~~~~~~~~~~~~~~~~

What I understand from this error is that the value from peekable() is not living long enough, which kind of makes sense to me. I'm only referencing the return in that line and calling another function which I imagine is returning a pointer to the character at the next location with the iterator. My naive solution to this was:

let mut peeker = self.src.peekable();
let res = peeker.peek();

If I implement this solution, I see a different error which also does not make sense to me:

error: cannot move out of borrowed content
       let mut peeker = self.src.peekable();
                        ^~~~

I'm not quite sure what's moving self out of a borrowed context here (I know it's borrowed from &self but not sure what's moving it out of the borrowed context.

EDIT

I proposed a question with details that were wildly inaccurate. The portion of the post that contained those details has been updated with actual facts - I mixed up two different situations where I had encountered a similar error (similar to me, at least).

Answer 1

Let's start with the second error.

As mentioned in the comments, Iterator::peekable is an iterator adapter that consumes the iterator it is going to make peekable. A small reproduction:

let values = [1,2,3];
let mut iterator = values.iter();
iterator.peekable(); // Consumes `iterator`
iterator.next(); // Not available anymore!

You can use Iterator::by_ref to get a reference that can then itself be consumed. Note that the underlying iterator will still be advanced!

let values = [1,2,3];
let mut iterator = values.iter();
iterator.by_ref().peekable();
iterator.next();

In your case, you are trying to consume the value out of a borrowed struct (via &self), which has the specific error cannot move out of borrowed content.

---

Let's look at your original error:

let values = [1,2,3];
let next = values.iter().peekable().peek();

The problem here is that peek returns a reference. This makes sense, as we don't know if the item we are iterating over is Copyable. However, that reference has to have somewhere to live. That place to live is the Peekable iterator itself! Peekable allocates enough space to store the "next" element. When you call peek, it advances the underlying iterator, stores the value, then returns the reference. Check out the function signature for peek to see this captured in code:

fn peek(&mut self) -> Option<&I::Item>

You can re-add the lifetimes to be explicit:

fn peek<'a>(&'a mut self) -> Option<&'a I::Item>

In the one-line version, you create and then destroy the Peekable, so there's nowhere for the value to live, so the reference dies in the same statement.