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();
}