Lifetime inference failure

[tomaka]

This code: (http://is.gd/tif86V)

struct Iter<'a>(&'a mut Vec<int>);

impl<'a> Iterator<&'a mut int> for Iter<'a> {
    fn next(&mut self) -> Option<&'a mut int> {
        self.0.as_mut_slice().get_mut(0)
    }
}

Produces this:

<anon>:5:16: 5:30 error: cannot infer an appropriate lifetime for autoref due to conflicting requirements
<anon>:5         self.0.as_mut_slice().get_mut(0)
                        ^~~~~~~~~~~~~~
<anon>:4:5: 6:6 help: consider using an explicit lifetime parameter as shown: fn next(&'a mut self) -> Option<&'a mut int>
<anon>:4     fn next(&mut self) -> Option<&'a mut int> {
<anon>:5         self.0.as_mut_slice().get_mut(0)
<anon>:6     }

I don't think there is anything unsafe with what I want to do (it's the exact same signature as MutItems).

This code does work but is incompatible with the Iterator trait definition: (http://is.gd/rMwbe6)

struct Iter<'a>(&'a mut Vec<int>);

impl<'a> Iter<'a> {
    fn next<'c: 'a>(&'c mut self) -> Option<&'a mut int> {
        self.0.as_mut_slice().get_mut(0)
    }
}

Sorry if this is a duplicate.

[steveklabnik]

You're going to have to write out the explicit lifetimes in this case. The 'inference' is just a set of simple rules: https://github.com/rust-lang/rfcs/blob/master/text/0141-lifetime-elision.md#the-rules

The elisison assigns the same lifetime to the self reference as the int reference, due to rule 3.

I'm not going to close this because I might be missing something, but that's what I see.

[japaric]

@tomaka Your code is not safe, and that's why it doesn't compile. If you call next() twice you'll end with two mutable references to the head of the vector.

// Calling `next` on an `Iterator` never freezes it, because of the signature of `next()`:
//    `next(&mut self) -> T`  // no lifetime "glue" between `self` and `T`
let head_mut: &mut T = iter.next();
let another_head_mut: &mut T = iter.next();

I don't think there is anything unsafe with what I want to do (it's the exact same signature as MutItems).

MutItems internally uses raw pointers for this reason, it's an unsafe operation.

This code does work but is incompatible with the Iterator trait definition

One possible (future) safe solution is HKT. The Iterator trait would need to change to:

trait Iterator<T> {
    // note: `T` is a "type constructor": lifetime -> concrete type
    fn next<'a>(&'a mut self) -> T<'a>;
}

With that definition and your implementation the iterator will "freeze" when next method is called, avoiding aliases to mutable memory.

let head_mut: &mut T = iter.next();  // `iter` gets frozen here
let another_head_mut: &mut T = iter.next();  //~ error: `iter` is already mutably borrowed

See this blog post (warning: old syntax) for more details.

[tomaka]

Thanks