[rust-dev] Question about lifetime analysis (a 0.5 transition question)

Niko Matsakis niko at alum.mit.edu
Sun Dec 30 13:16:02 PST 2012


The errors you are seeing now are in fact related to borrowing @T 
values, as suggested in a previous message.  In this case, your problem 
is that you need to have values with the same lifetime as the this 
pointer, but the default match construct copies value out.  This means 
that the lifetime of the copied-out values is limited to the current 
stack frame.  You can address this using `ref` mode. Unfortunately, due 
to the bug with lifetime inference cited earlier, you will need to 
provide explicit hints to help the type checker out. Hopefully this will 
be fixed soon.

In any case, I've made the requisite changes here:

https://github.com/nikomatsakis/rustled/commit/aea45eeeea2b328f5f3c6515de21be2039a9498d 


and opened a pull request:

https://github.com/stevej/rustled/pull/1


regards,
Niko


Steve Jenson wrote:
> On Thu, Dec 27, 2012 at 3:16 PM, Niko Matsakis <niko at alum.mit.edu 
> <mailto:niko at alum.mit.edu>> wrote:
>
>     I'm sorry for not replying more quickly, I was not checking e-mail
>     over xmas break.  I do not know of any general problems with @ and
>     borrowing.  In any event, this is a misdiagnosis.
>
>
> No problem with reply timing.
>
>     The problem is this: the declaration of iter looks like this:
>
>         impl<K: Copy Eq Ord, V: Copy> RBMap<K, V>: iter::BaseIter<(&K,
>     &V)>
>
>     In the context of a type declaration, an & means `&self`, where
>     `self` is the lifetime parameter associated with the
>     type/impl/whatever (just as the impl has two type parameters K and
>     V, it also has an implicit lifetime parameter `self`).  So, this
>     declaration written out more explicitly would be:
>
>     impl<K: Copy Eq Ord, V: Copy> RBMap<K, V>:
>     iter::BaseIter<(&self/K, &self/V)>
>
>     However, your method declaration is:
>
>         pure fn each(&self, f: fn(&(&K, &V)) -> bool) { ... }
>
>     In the context of a function declaration, & means "a fresh
>     lifetime".  So this winds up being short for a declaration life this:
>
>         pure fn each(&self, f: fn(&a/(&a/K, &a/V)) -> bool) { ... }
>
>     However, the trait declares that `each` should have this type:
>
>         pure fn each(&self, f: fn(&a/(&self/K, &self/V)) -> bool) { ... }
>
>     So I think that if you change your declaraiton of `each()` to:
>
>         pure fn each(&self, f: fn(&(&self/K, &self/V)) -> bool) { ... }
>
>     It will work just fine.  I apologize for the cryptic error
>     message.  Working on it.
>
>
> Unfortunately not but a much more interesting set of error messages 
> about lifetimes is coming out now: http://pastebin.com/SYwCw1ac
>
> And here is a link to the each method again (I pushed this broken 
> version to github so I can share the exact changes I made)
>
> https://github.com/stevej/rustled/blob/master/red_black_tree.rs#L96
>
> Thanks a bunch for all of your clarifying comments and blog posts.
>
> Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20121230/0059a4d1/attachment.html>


More information about the Rust-dev mailing list