too-many-lists | Learn Rust by writing Entirely Too Many linked lists | Learning library

When I saw the title of your question I immediately wanted to post a link to that "Learning Rust via too many linked lists" book, but I see you're already on to that :)

Ah, it's all so very messy, isn't it? Well in your case the solution is quite simple.

First, the type of curr_node should be &mut Link and thus needs to also be initialized with &mut self.head because we need a mutable reference.

Next, in your while loop you are using pattern matching to bind the value of the node to your variable node. However, pattern matching by default moves the matched value into the variable, and that's why the compiler complains: You can't just up and move elements out of a struct.

Instead of moving, we just want to grab a reference to the node, so we say while let Link::More(ref mut node) = curr.node { ... }

and then finally curr_node = &mut node.next because again we need a mutable reference.

Playground Link

Can the use statement be fixed while the main remains there?

No, super will refer to the encompassing module, not the function scope. There is no path that can name it as far as I'm aware. You could wrap everything within main in another module, so super can find it that way:

Yes, you are absolutely right. The whole point of implementing Drop in that tutorial is to avoid a recursive call, and your implementation achieves the same thing using less code (and with less assembly at the end).

Having said that, the implementation in the tutorial is a lot more explicit, and it could be argued that it is easier to see what is going on. The mem::replace ensures that the Link is replaced with an Empty, making it clear that all of the boxes are dropped too. This might have been a conscious decision by the tutorial authors, or it could have been an oversight.

The bonus section might also give a clue as to what the author was thinking. Their idea of simplifying the Drop implementation was to add a method which is useful for simplifying other methods too, and therefore would still need to maintain the integrity of the structure. The fact that this isn't necessary in a Drop implementation may have passed them by while looking at the bigger picture, or else they may have specifically wanted that implementation so that the bonus section makes sense.

Your version is probably more efficient, but might take a second glance to understand what it is really doing. I'd still go with yours though, since it is shorter and is doing less work.

Answered by u/quixotrykd/:

The compiler seems to be choking here because it doesn't know how the lifetime on &mut self and ThreadIterator relate. As such, it has no way to guarantee that &mut self lives at least as long as the underlying borrow in ThreadIterator. Looking at your code here, that would be line 12 (note I've fixed your mistake in the above link).

You need to tell the compiler that the lifetime on the output ThreadIterator is the same as the input &mut self (or technically that it lasts at least as long, though you very likely want the same lifetime here), otherwise the compiler has no way to ensure that the "self" that's borrowed by &mut self stick around as long as the ThreadIterator's borrow. Looking at the rules for lifetime elision here, we can see that this doesn't apply to your code, and as such, you need to manually specify the lifetime on &mut self (otherwise it generates another, unrelated, anonymous lifetime, as indicated in the compiler's error message).

The fixed code:

Rust is trying to say that you have a dangling reference.