On 05/29/2013 04:55 AM, Niko Matsakis wrote:
> On Tue, May 28, 2013 at 01:48:55PM -0500, Tommy M. McGuire wrote:
>> The problem I am running into is that the type of the LinearMap's find()
>> method (Yes, this is 0.6.) is:
>>
>> fn find(&self, k: &&'b [u8]) -> Option<&'self &'b [u8]>
>>
>> In other words, the key argument is a borrowed pointer to a borrowed
>> pointer to a vector with the same lifetime as the buffer. That argument
>> is kind of difficult to provide.
>
> First, I'm sure you've heard this before, but you'll probably be
> happier if you bite the bullet and upgrade to incoming. There are a
> lot of bugs fixed around the treatment of lifetimes, and more to come.
Yes, yes. I know. :-) I'm in the process of doing that, now.
> That said, why is a `&&[u8]` so difficult to provide? You can do
> something like this:
>
> let my_slice: &[u8] = my_vec.slice(from, to);
> match map.find(&my_slice) { ... }
>
> Or even:
>
> match map.find(&my_vec.slice(from, to)) { ... }
>
>> What am I doing wrong? Is there a better way?
>
> I think you are doing it right. You may find it easier to just put
> indices into the map rather than slices, but slices should work too.
The problem is that I want to use a completely unrelated vector as the
argument to find() instead of an alias for part of the buffer or a pair
of indices into the buffer.
Currently, with my quick change to incoming, the code
let kkey : &[u8] = key; // key : ~[u8]
match dictionary.find(&kkey) {
produces:
55:38 error: borrowed value does not live long enough
let kkey : &[u8] = key;
^~~
67:1 note: borrowed pointer must be valid for the lifetime
&br_named({repr: 83, ctxt: 0}) as defined on the block at 48:0...
...
65:5 note: ...but borrowed value is only valid for the block at 50:46
The lifetime '&br_named(...)' stuff should be "'b", the lifetime
parameter of the function (the block at 48:0) that is associated with
the keys and values from the HashMap (was LinearMap) and the buffer.
Here's the complete file:
https://gist.github.com/tmmcguire/5674103#file-gistfile1-rs
--
Tommy M. McGuire
[email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
