7 ms·

Common Rust Lifetime Misconceptions

178 points by donmcc 6y ago

est31 6y ago
> T only contains owned types I'd say this is true, because I consider &mut T and &T to be owned types in their own right. They own a pointer. I can cast them to raw pointers. &T impl's Copy even if T doesn't. https://doc.rust-lang.org/1.43.1/src/core/marker.rs.html#794 https://doc.rust-lang.org/1.43.1/src/core/marker.rs.html#794 Otherwise, the compilation is great.
- whyever 6y ago
  This is not how the author uses the word owned.
  - est31 6y ago
    If you use the author's definition of the owned term as "some non-reference type, e.g. i32, String, Vec, etc", the misconception is indeed one. But I disagree with the definition.
- justinpombrio 6y ago
  Is there any type that is _not_ owned by this definition?
  - Rusky 6y ago
    Not really- which is why "owned type" is kind of imprecise and usually just means "a type not constrained by any lifetime."
joaomoreno 6y ago
This is a fantastic article, please someone bump this up to the Rust book.
antpls 6y ago
Reading this document suddenly made learning Rust a lot scarier, and also increases my respect to Rust developers (people writing programs in Rust). It kind of shows that increased safety doesn't come for free.
- kd5bjo 6y ago
  For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advanced Rust concepts, and most programmers can eventually learn them from experience fighting with the compiler.
  - Someone 6y ago
    If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”. That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”. The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership. For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules. Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.
    - kd5bjo 6y ago
      You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else. My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.
    - naasking 6y ago
k__ 6y ago
Coming from JS it was rather counterintuitive for me that a function would "own" a value even if it was ran synchronously and finished. Also, the whole 'move' terminology sounded to me like Rust would move memory around, but it usually referred to the move of ownership. Also 'consume' didn't make no sense to me. "into_iter consumes a vector" what does it mean? Where does the vector go? The most valuable info I got about lifetimes was: references/borrowing is usually what you want, so always throw in a &.
- mikekchar 6y ago
  Generally speaking, I've found Rust terminology confusing. For example, why does the `IntoIter` iterator gives you owned values? What the heck does "Into" mean to a Rust developer? There are lots of things like that. I've found that fluency in Rust is partly trying to understand the concepts and partly just learning to understand the specific meanings of certain vocabulary. I've likened it to working with Ruby on Rails. There are a lot of useful facilities, but they practically force you to think exactly like the original author -- who doesn't seem to quite speak like I do.
  - littlestymaar 6y ago
    > What the heck does "Into" mean to a Rust developer? Into means it will consume the value (you don't have it anymore): https://doc.rust-lang.org/1.0.0/style/style/naming/conversions.html https://doc.rust-lang.org/1.0.0/style/style/naming/conversio...
    - steveklabnik 6y ago
      (Please note this document is outdated; you’ve linked to the 1.0.0 docs. This particular page is pretty ok but we don’t ship this at all anymore, and haven’t for years.)
      - ChrisSD 6y ago
        I think the maintained equivalent would be in the Rust API guidelines: https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv https://rust-lang.github.io/api-guidelines/naming.html#ad-ho...

178 points by donmcc 6y ago

> T only contains owned types I'd say this is true, because I consider &mut T and &T to be owned types in their own right. They own a pointer. I can cast them to raw pointers. &T impl's Copy even if T doesn't. https://doc.rust-lang.org/1.43.1/src/core/marker.rs.html#794 https://doc.rust-lang.org/1.43.1/src/core/marker.rs.html#794 Otherwise, the compilation is great.

whyever 6y ago
This is not how the author uses the word owned.
- est31 6y ago
  If you use the author's definition of the owned term as "some non-reference type, e.g. i32, String, Vec, etc", the misconception is indeed one. But I disagree with the definition.
justinpombrio 6y ago
Is there any type that is _not_ owned by this definition?
- Rusky 6y ago
  Not really- which is why "owned type" is kind of imprecise and usually just means "a type not constrained by any lifetime."

joaomoreno 6y ago

This is a fantastic article, please someone bump this up to the Rust book.

antpls 6y ago

Reading this document suddenly made learning Rust a lot scarier, and also increases my respect to Rust developers (people writing programs in Rust). It kind of shows that increased safety doesn't come for free.

kd5bjo 6y ago
For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advanced Rust concepts, and most programmers can eventually learn them from experience fighting with the compiler.
- Someone 6y ago
  If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”. That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”. The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership. For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules. Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.
  - kd5bjo 6y ago
    You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else. My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.
  - naasking 6y ago

k__ 6y ago

Coming from JS it was rather counterintuitive for me that a function would "own" a value even if it was ran synchronously and finished. Also, the whole 'move' terminology sounded to me like Rust would move memory around, but it usually referred to the move of ownership. Also 'consume' didn't make no sense to me. "into_iter consumes a vector" what does it mean? Where does the vector go? The most valuable info I got about lifetimes was: references/borrowing is usually what you want, so always throw in a &.

mikekchar 6y ago
Generally speaking, I've found Rust terminology confusing. For example, why does the `IntoIter` iterator gives you owned values? What the heck does "Into" mean to a Rust developer? There are lots of things like that. I've found that fluency in Rust is partly trying to understand the concepts and partly just learning to understand the specific meanings of certain vocabulary. I've likened it to working with Ruby on Rails. There are a lot of useful facilities, but they practically force you to think exactly like the original author -- who doesn't seem to quite speak like I do.
- littlestymaar 6y ago
  > What the heck does "Into" mean to a Rust developer? Into means it will consume the value (you don't have it anymore): https://doc.rust-lang.org/1.0.0/style/style/naming/conversions.html https://doc.rust-lang.org/1.0.0/style/style/naming/conversio...
  - steveklabnik 6y ago
    (Please note this document is outdated; you’ve linked to the 1.0.0 docs. This particular page is pretty ok but we don’t ship this at all anymore, and haven’t for years.)
    - ChrisSD 6y ago
      I think the maintained equivalent would be in the Rust API guidelines: https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv https://rust-lang.github.io/api-guidelines/naming.html#ad-ho...