Understanding Rust Lifetimes 

C & C++ Programmers would be like, ow this is much easier. people coming from GC language " what the heck have i been watching for an hour "

Ok, it took me a bit to understand why the std::mem::replace method works. So here is how I see it: Normally, element is a mutable reference to self.slice[0]. This mutable reference has lifetime 'next, because it is defined within the next function that has a lifetime of 'next. We need to make it have a lifetime of 'iter instead. The only mutable reference to self.slice with a lifetime of 'iter is self.slice itself. So when you do 'let slice = &mut self.slice;', you are creating a mutable reference to self.slice, with lifetime 'next since it is defined in the next function. Then std::mem::replace takes that mutable reference with lifetime 'next, **dereferences** it and sees a mutable reference to self.slice with lifetime 'iter, and returns it to us which is exactly what we want. It is the fact that it dereferences the 'dest' function parameter and returning it (with the lifetime associated with it) which makes it work. -I think it would have been a bit clearer if at --1:06:23--, you would have used 'let slice2 = std::mem::replace(slice, &mut []);' because it is a bit confusing when you see that slice is being replaced with '&mut []', and it's old value is being bound to slice again.- You did this as 1:08:26, I should have watched it through before commenting! I had to draw it out to see how it worked, but I'm glad I did because I think I get it now :D

TIL (finally) why you have to annotate lifetimes and generic parameters twice in the impl signature! Thank you Ryan again for the awesome tutorial!

For the longest time I kept thinking, "who is this know-it-all Chad fella? And why is he asking all the questions?"!! 🤦🏽‍♂️ Love the content.

Your content really is the best. Thank you. I’m totally inspired.

56:40 I think it comes down to a simple fact. If the data is guaranteed to exist (immutably), and it won't be changed ever (because we enforced mutable borrow laws, so you can't read the data after it has been mutably borrowed), and because we know how long the data will last for (up to the highest lifetime), then because of all these conditions, we can say for certain that the data referenced there will ALWAYS be the same, so it is safe to lengthen it to the longest lifetime in that case (regardless that it was borrowed as 'next). I suppose that in this case, the reference from 'next effectively == 'a

Finally I found someone discussing Lifetimes up to advance usage. Ive been struggling to understand lifetimes.

I really like your instruction style, Ryan; thanks for doing this. @35:30 I think the question was this: If I write a function that returns an iterator, should the function signature specify the concrete iterator type that is returned, or should it use "impl Iterator"? And the answer, I believe, is that in general it is better to use "impl Iterator." To be more precise about it, fn foo(...) -> impl Iterator {...} is better than fn foo(...) -> MyIterator {...} It is better in that it preserves flexibility in the implementation -- later you might want to return some other type. If all you promised was that you would return SOMETHING that implements Iterator, then you can make that change. If you promised that you would return a MyIterator, then changing that would be a breaking change in your API.

This is amazing. I finally understand something of Lifetime. Your content is gold! :D

This is by far the best video about Rust lifetime. thank you so much. Would be great if you can post more videos about Rust like async 😊

This is great content! Please keep it up. I don't spend much time on twitch but will start to try and watch you live

Where you said that T must live as long as struct, that literally made this make more sense than all the countless guides I read 25:00 "it's more code" \*ends up being less code\*

A totally underrated guy. Thank you, Ryan!

Thank you, Ryan. You are really good at explaining Rust. Your voice is awesome, too.

1:07:37 Isn't it a bit better to use std::mem::take() instead? You're replacing it with a default, and take() should do just that

Hey, I got a question: isn't it weird that we can std::mem::replace effectively self.slice temporarily with &mut []? AFAIK shouldn't any contents of self.slice need to have a lifetime of 'iter (which is clearly not the case with &mut [], which should live on the function stack)? Is this just a special elision trick where the compiler proves that self.slice is never actually invalid or am I missing something?

You can move out of self.slice directly by passing &mut self.slice into std::mem::replace(). No need for a placeholder borrow. Thanks for another great stream Ryan, do you know if there’s work being done to make forwarding of lifetimes like this easier?

I haven't written a line of rust yet (cant figure out a project to do) but it would seem that, in the first iteration of the Iterator implementation where you check if the slice.is_empty and return none, that code could panic with a index out of bounds/range "exception" when self.slice has a single item in it. (Unless slice[1..] returns differently than i would expect.) edit I would also like to note that I appreciate it when you repeat the questions from chat (which you have done consistently throughout this and other videos).

Great video... as usual But there is just one thing that bothers me. It's been mentioned multiple times throughout the video by people in chat that it is impossible to implement mutable iterator without unsafe code and Ryan telling all of us to just wait and see how it is done. Then he shows us "a trick" with std::mem::replace but if you look at its implementation (doc.rust-lang.org/std/mem/fn.replace.html - click on src link) then you see that this method is just a small unsafe block, essentially meaning that we couldn't avoid using unsafe

BTW, your cursor is black against black - it was very hard to see when you were point out items in the code.

Super nice! Very well explained! Just subscribed to the twitch channel.

Some people feel shame over the realization "Why didn't I think if this? It's so obvious now that I see it!". I don't, because that feeling just means that I learned something that I know I would have needed several times before, and - more importantly - will need again in the future. Going back to review an ugly hack I did in a tokio Decoder.. :)

Amazingly helpful video. Thank you

Insightful, mYbe the most insightful explanation and demo of lifetimes. Thanks!

So basically it prevents the situation that you borrow a book at the library due next month and find out while reading that the pages inside have to be returned tomorrow 🤔

This was a really nice and helpful explanation for lifetimes! Thanks!

Thanks Ryan. As always, very insightful. 48:48, did you mean "we can't have multiple 'writers' at the same time?" (i heard 'readers')

Thank you for this!

Simply fabulous!

you helped me a lot, thanks

Thanks Ryan!

Just like in "The Raiders of the Lost Arc". Fingers crossed the borrow checker isn't sending a giant rolling boulder your way. Couldn't this dummy replace trick be added to the standard library as a means to grab the original pointer?

awesome!! love your rust content

How is it that split_first is not named car_cdr ... I don't get it.

Question: what is the a problem with using 'iter lifetime for the mut self in the next function? That is, instead of using fn next(&'next mut self), why not just use fn next(&'iter mut self) to enforce the same lifetime is used for both the iterator and each item?

Thanks Ryan! Very helpful.

Does mem::replace () accepts a pointer to a pointer ?

what linting extension is being used for your vscode? That's pretty neat.

Would be very cool if you'd put a list of your vs code extensions in some link in the description

Q: Is there a differance between std::mem::replace() and core::mem::replace()? why exist in std? I'm coming at Rust from microcontroller space where there is no OS. My impression is that Rust is only recently viable here. The no GC is very attractive for microcontrollers where I want dynamic behaviour with accurate timing always.

Thank you so much for this one!

Hi and thanks for this video. I learn rust right now and of course borrowing and life time are really a little montain to grow. I will see over videos from you channel and one of my question actually is, ilke a lot on persons i guess, i comes from object programming and with rust, it seems not to be a good paradigm to code efficiently, because of the temptation to referencing multiples objects each overs for example. Is exists some good tutorial or book who talk about good rust paradigms and how to organize and write good rust program ? Thanks and have a good day.

Awesome, Thank you!

Thanks for that awesome video. That was way better than reading any book. I think using `slice: Option

I'll be your friend. U r awesome.

Sooo... MyMutableIterator::next needs to last as long as MyMutableIterator last, and it is understandable, but why then the `next` function has to have its own " 'next" lifetime? Would not it work if the `next` function would have a " 'iter" lifetime? Like this: fn next(& 'iter mut self) -> Option { ... } and then the function body would look the same as the immutable one.

This is blood magic (memory being the blood).

Hello, I'm very interested in how &self.slice[1..] works If we have 1 element left in the slice, then we can get it through [0], but if we use [1] then it will be out of range, then how does &self.slice[1..] work when we have 1 element?

std::mem::replace is hard to understand

why do you only get the conflicting requirements error when you do it with mutable references? Why doesn't it complain when you do it with immutable references?

I had the exact same issue this weekend and I found the book lacking a bit in this context. What would be the in your opinion another way to get the same result without using the mem::replace trick? Can you extend the lifetime of the returned value to the struct lifetime? Thanks for the content anyway! ;)

So... the mutable borrow of the empty slice... does it have a lifetime of `static?

very nice !

i used rust last time but i find it overly complex..its not much different from c++ except no more header files..other than that, its not much different from c++..its anoyying to use..is it really worth it? making linked list in rust alone make me wanna break my keyboard

ok :]