
Common Rust Lifetime Misconceptions - donmcc
https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md
======
est31
> 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.

~~~
justinpombrio
Is there any type that is _not_ owned by this definition?

~~~
Rusky
Not really- which is why "owned type" is kind of imprecise and usually just
means "a type not constrained by any lifetime."

------
antpls
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.

~~~
pretzelhammer
Hi, document author here. I learned Rust because I was too scared to learn
C++, lol.

Rust has a steeper learning curve than most languages but it also has a very
beginner-friendly and welcoming community. So don't be scared, you can do it!
If you get stuck on something it's always easy to get help.

~~~
wyufro
As someone who doesn't know Rust yet I feel there's a "do this instead"
missing to point 8. It's not clear to me how to do it instead.

------
k__
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 &.

~~~
cesarb
> Also, the whole 'move' terminology sounded to me like Rust would move memory
> around

That's exactly what happens: a Rust "move" is under the covers a memcpy().

> but it usually referred to the move of ownership.

That's also what happens. For instance, when you move a Vec, you are moving
(through memcpy) only three words of memory (a pointer, the length, and the
capacity), but you are also "moving" the ownership of the memory behind that
pointer. That is, the new Vec is responsible for managing that memory, and the
old Vec can no longer be used.

> Also 'consume' didn't make no sense to me. "into_iter consumes a vector"
> what does it mean?

It means that it takes ownership of the vector, and doesn't give it back.

> Where does the vector go?

It's destroyed within that function. In the case of into_iter() of a vector,
it's broken into its component parts (the pointer, the length, and the
capacity), and the struct into_iter() returns (which is not a Vec, but
something else) is now responsible for managing the memory behind the pointer,
and releasing that memory once it's no longer needed.

~~~
Asraelite
> That's exactly what happens: a Rust "move" is under the covers a memcpy().

Is it really? I had always assumed that the compiler would almost always
optimize a move down to nothing, simply reusing the address. If access to the
address is still exclusive, what would be the benefit of moving it in memory?

memcpy sounds like what would happen in the case of a copy or clone, not a
move.

~~~
cesarb
Yes, the optimizer (LLVM) can often optimize memcpy(), and this is not
exclusive to Rust: the same optimizations happen with C and C++ (a well-known
trick to avoid some undefined behaviors in C is to do a memcpy(), which the
optimizer will then elide). It doesn't change that, before the optimization
passes, it's doing the equivalent of a memcpy().

> memcpy sounds like what would happen in the case of a copy or clone, not a
> move.

In Rust, copy and move are nearly identical; the only difference is that,
after a move, the compiler doesn't let you access the old value. Clone is
different, since it can be overridden to do anything the programmer desires,
but by default, it's identical to copy.

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

