I was looking through the singly linked list example on rustbyexample.com and I noticed the implementation had no append
method, so I decided to try and implement it:
fn append(self, elem: u32) -> List {
let mut node = &self;
loop {
match *node {
Cons(_, ref tail) => {
node = tail;
},
Nil => {
node.prepend(elem);
break;
},
}
}
return self;
}
The above is one of many different attempts, but I cannot seem to find a way to iterate down to the tail and modify it, then somehow return the head, without upsetting the borrow checker in some way.
I am trying to figure out a solution that doesn't involve copying data or doing additional bookkeeping outside the append
method.
So, it's actually going to be slightly more difficult than you may think; mostly because
Box
is really missing a destructivetake
method which would return its content.Easy way: the recursive way, no return.
This is relatively easy, as mentioned.
Harder way: the recursive way, with return.
Note that this is grossly inefficient. For a list of size N, we are destroying N boxes and allocating N new ones. In place mutation (the first approach), was much better in this regard.
Harder way: the iterative way, with no return.
Okay... so iterating (mutably) over a nested data structure is not THAT easy because ownership and borrow-checking will ensure that:
This is why here:
{current}
to movecurrent
into the match,c @ &mut Nil
because we need a to name the match of&mut Nil
sincecurrent
has been moved.Note that thankfully rustc is smart enough to check the execution path and detect that it's okay to continue looping as long as we take the
Cons
branch since we reinitializecurrent
in that branch, however it's not okay to continue after taking theNil
branch, which forces us to terminate the loop :)Harder way: the iterative way, with return
In the recursive way, we were using the stack to keep the items for us, here we use a stack structure instead.
It's even more inefficient than the recursive way with return was; each node cause two deallocations and two allocations.
TL;DR: in-place modifications are generally more efficient, don't be afraid of using them when necessary.
As the
len
method is implemented recursively, I have done the same for theappend
implementation:One possible iterative solution would be to implement
append
in terms ofprepend
and a reverse function, like so (it won't be as performant but should still only be O(N)):As described in Cannot obtain a mutable reference when iterating a recursive structure: cannot borrow as mutable more than once at a time, you need to transfer ownership of the mutable reference when performing iteration. This is needed to ensure you never have two mutable references to the same thing.
We use similar code as that Q&A to get a mutable reference to the last item (
back
) which will always be theNil
variant. We then call it and set thatNil
item to aCons
. We wrap all that with a by-value function because that's what the API wants.No extra allocation, no risk of running out of stack frames.
When non-lexical lifetimes are enabled, this function can be more obvious: