Moved variable still borrowing after calling `drop`?

by

I can’t give you a definite answer, but I’ll try to explain a few things here. Let’s start with clarifying something:

The compiler knows drop() drops x

This is not true. While there are a few “magic” things in the standard library that the compiler knows about, drop() is not such a lang item. In fact, you could implement drop() yourself and it’s actually the easiest thing to do:

fn drop<T>(_: T) {}

The function just takes something by value (thus, it’s moved into drop()) and since nothing happens inside of drop(), this value is dropped at the end of the scope, like in any other function. So: the compiler doesn’t know x is dropped, it just knows x is moved.

As you might have noticed, the compiler error stays the same regardless of whether or not we add the drop() call. Right now, the compiler will only look at the scope of a variable when it comes to references. From Niko Matsakis’ intro to NLL:

The way that the compiler currently works, assigning a reference into a variable means that its lifetime must be as large as the entire scope of that variable.

And in a later blog post of his:

In particular, today, once a lifetime must extend beyond the boundaries of a single statement […], it must extend all the way till the end of the enclosing block.

This is exactly what happens here, so yes, your problem has to do with all this “lexical borrowing” stuff. From the current compilers perspective, the lifetime of the expression &a needs to be at least as large as the scope of x. But this doesn’t work, since the reference would outlive a, since the scope of x is larger than the scope of a as pointed out by the compiler:

= note: values in a scope are dropped in the opposite order they are created

And I guess you already know all that, but you can fix your example by swapping the lines let mut x ...; and let a ...;.

I’m not sure whether or not this exact problem would be solved by any of the currently proposed solutions. But I hope that we will see soon enough, as all of this is being addressed as part of the Rust 2017 roadmap. A good place to read up on the updates is here (which also contains links to the five relevant blog posts of Niko).

More Related Contents:

  1. Why can’t I store a value and a reference to that value in the same struct?
  2. What are non-lexical lifetimes?
  3. The compiler suggests I add a ‘static lifetime because the parameter type may not live long enough, but I don’t think that’s what I want
  4. How can I create my own data structure with an iterator that returns mutable references?
  5. Lifetime error when creating a function that returns a value implementing serde::Deserialize
  6. Why does linking lifetimes matter only with mutable references?
  7. Why is adding a lifetime to a trait with the plus operator (Iterator + ‘a) needed?
  8. Cannot infer an appropriate lifetime for autoref due to conflicting requirements
  9. When is it useful to define multiple lifetimes in a struct?
  10. Lifetime troubles sharing references between threads
  11. What is lifetime elision in very simple terms?
  12. “borrowed value does not live long enough” when using the builder pattern
  13. How can this instance seemingly outlive its own parameter lifetime?
  14. How do I specify lifetime parameters in an associated type?
  15. How to operate on 2 mutable slices of a Rust array?
  16. When returning the outcome of consuming a StdinLock, why was the borrow to stdin retained?
  17. Why does my variable not live long enough?
  18. Why is the bound `T: ‘a` required in order to store a reference `&’a T`?
  19. Sharing a struct with trait objects as properties across threads
  20. Why can’t I return an &str value generated from a String?
  21. Type mismatches resolving a closure that takes arguments by reference
  22. How to fix lifetime error when function returns a serde Deserialize type?
  23. Why does Rust disallow mutable aliasing?
  24. Extend lifetime of variable
  25. Why does the Rust compiler request I constrain a generic type parameter’s lifetime (error E0309)?
  26. How do I implement the Add trait for a reference to a struct?
  27. Converting from Option to Option
  28. If BufReader takes ownership of a stream, how can I read and write lines on it?
  29. Sized is not implemented for the type Fn
  30. How does Rust’s type inference work across multiple statements?

Leave a Comment