sixth: Add sixth.rs, fix split_before and split_after edge cases

[morlinbrot]

Fixes #238

Both methods returned illegal lists when the cursor was at the first or last node respectively.

Note that I PR'd the same fix over on contain-rs/linked-list but the implementation is slightly different. Here, we are still setting the head/tail optimistically as before but remove it again later (when encountering the edge case):

let mut output_front = self.list.front;

if let Some(prev) = prev {
    (*cur.as_ptr()).front = None;
    (*prev.as_ptr()).back = None;
} else {
    // We're at the first node, need to unset the head we "optimistically" set before.
    output_front = None;
}

It seemed to me that this fit better into the flow of the article. Difference to the implementation I did before:

// We might be at the first node, in which case we don't want to set a new list.front but return an empty list.
let mut output_front = None;

if let Some(prev) = prev {
    (*cur.as_ptr()).front = None;
    (*prev.as_ptr()).back = None;
    output_front = self.list.front
}

My OCD prefers the latter version as we only ever set the head when it is actually required instead of setting and then maybe unsetting again. Let me know if you prefer any version and I will update any one of the PRs to unify the implementations, if desired.

[irbull]

+1. I just stumbled upon this too and filed #300. I have a small change-set to fix this, although I did it in a slightly different way. I put an explicit case for if len == 0, set front / back to None. I thought it fit nicely in the article as it isolates the specific case that was originally missed. Here are some tests that also show the bug:

     #[test]
    fn test_empty_slice() {
        let mut list = LinkedList::new();
        list.push_back(7);
        list.push_back(8);
        list.push_back(9);

        let mut cur = list.cursor_mut();
        cur.move_next(); // Point at the first node
        let result = cur.split_before(); // Everything before the first node

        assert_eq!(result.len, 0);
        assert_eq!(result.front(), None);
        assert_eq!(result.back(), None);

        assert_eq!(list.len, 3);
        assert_eq!(list.front(), Some(7).as_ref());

        let mut cur = list.cursor_mut();
        cur.move_prev(); // Point at the last node
        let result = cur.split_after(); // Everything after the last node

        assert_eq!(result.len, 0);
        assert_eq!(result.front(), None);
        assert_eq!(result.back(), None);
    }

But since you already have a PR and since it seems none of the PRs here are being merged, I don't think I'll bother. This was a great exercise in learning about the lists.

[quasiyoke]

I think that making the calculation of the result's length explicit will make a potential problem more noticeable. Currently, it's calculated through several intermediate indirect values:

output_len = old_len - new_len =
           = old_len - (old_len - old_idx) =
           = old_idx

In my opinion, after we saw that output_len = old_idx, it seems obvious to handle the "index equals zero" situation (since this is the primary index value we usually consider).

If you begin by assigning values to output_front and output_back without mutable binding:

let output_len = self.index.unwrap();
let (output_front, output_back) = if output_len == 0 {
    (None, None)
} else {

— you're likely to soon find it simpler to handle the special case of an empty output via an early exit:

if output_len == 0 {
    return LinkedList::new();
}

[morlinbrot]

You're right, if we remove the indirection from computing output_len, we arrive at the fact that there is an edge case that we can make more explicit.

Using a match statement on self.index to express this, we'd arrive at the following:

match self.index {
    // The original `else` block, an empty list
    None => std::mem::replace(self.list, LinkedList::new())
    // Newly identfied edge case: list of length 1
    Some(0) => LinkedList::new(),
    // Remaining cases
    Some(idx) => {
      // ...
    }

This way, we can keep the remaining cases match arm completely free of edge cases and a bit smaller.

Funnily enough, this is very close to what I had also arrived at with my own implementation which I used in my PR over at contain-rs/linked-list. There, for actual library code, I focused on being as clean and concise as possible. Here, I initially chose to keep edits to a minimum as to not change the original structure of the code too much, thinking it could conflict with the narrative of the article.

But having thought about it now, I agree that a more explicit version fits very well. The chapter's narrative is all about reducing the number of things to keep in your head and a more explicit version does exactly that.

I've updated the PR accordingly, thanks for the careful review!