On May 30, 2014, at 12:12 AM, Vladimir Matveev <dpx.infin...@gmail.com> wrote:
> 2014-05-30 5:37 GMT+04:00 Kevin Ballard <ke...@sb.org>:
>>
>> It shouldn't.
>>
>> The for-loop desugaring looks like
>>
>> match &mut st.execute_query() {
>> __i => loop {
>> match __i.next() {
>> None => break,
>> Some(mut __value) => {
>> let i = __value;
>> {
>> // for loop body goes here
>> }
>> }
>> }
>> }
>> }
>>
>> It's done with a match statement like this specifically to make the &mut
>> binding of the iterator end after the for loop.
>
> Great, didn't know it. Last time I asked (on StackOverflow, I think;
> that was some time ago though) there were no `match`. Then from that
> code alone it does look like a bug to me. Note that it refers to
> `st.set_string("%e%")` and `for` loop ten lines above, that is, the
> first one. If mutable borrow of the iterator aren't escaping the loop,
> then this error should not appear, right?
The errors you printed are slightly malformed, and you only listed some of your
code. Is this a database library you're writing yourself? My best guess here is
that you've accidentally used the wrong lifetime on your `execute_query()`
method, tying the lifetime of the `self` reference to a lifetime on the value
itself. Something like this:
impl<'a> Statement<'a> {
pub fn execute_query(&'a mut self) { ... }
}
By using 'a on &'a mut self here, you've explicitly tied the reference to the
lifetime of the value. This causes the mutable reference to live much longer
than you expected it to, which means it's still alive when you try to
subsequently borrow it on your call to .set_string().
-Kevin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
