strsplit.rs

#![warn(rust_2018_idioms)]

#[derive(Debug)]
pub struct StrSplit<'haystack, D> {
    remainder: Option<&'haystack str>,
    delimiter: D,
}

impl<'haystack, D> StrSplit<'haystack, D> {
    pub fn new(haystack: &'haystack str, delimiter: D) -> Self {
        Self {
            remainder: Some(haystack),
            delimiter,
        }
    }
}

pub trait Delimiter {
    fn find_next(&self, s: &str) -> Option<(usize, usize)>;
}

impl<'haystack, D> Iterator for StrSplit<'haystack, D>
where
    D: Delimiter,
{
    type Item = &'haystack str;
    fn next(&mut self) -> Option<Self::Item> {
        let remainder = self.remainder.as_mut()?;
        if let Some((delim_start, delim_end)) = self.delimiter.find_next(remainder) {
            let until_delimiter = &remainder[..delim_start];
            *remainder = &remainder[delim_end..];
            Some(until_delimiter)
        } else {
            self.remainder.take()
        }
    }
}

impl Delimiter for &str {
    fn find_next(&self, s: &str) -> Option<(usize, usize)> {
        s.find(self).map(|start| (start, start + self.len()))
    }
}

impl Delimiter for char {
    fn find_next(&self, s: &str) -> Option<(usize, usize)> {
        s.char_indices()
            .find(|(_, c)| c == self)
            .map(|(start, _)| (start, start + self.len_utf8()))
    }
}

pub fn until_char(s: &str, c: char) -> &'_ str {
    StrSplit::new(s, c)
        .next()
        .expect("StrSplit always gives at least one result")
}

#[test]
fn until_char_test() {
    assert_eq!(until_char("hello world", 'o'), "hell");
}

#[test]
fn it_works() {
    let haystack = "a b c d e";
    let letters: Vec<_> = StrSplit::new(haystack, " ").collect();
    assert_eq!(letters, vec!["a", "b", "c", "d", "e"]);
}

#[test]
fn tail() {
    let haystack = "a b c d ";
    let letters: Vec<_> = StrSplit::new(haystack, " ").collect();
    assert_eq!(letters, vec!["a", "b", "c", "d", ""]);
}

Hey @jonhoo, how common is it to see or do:

impl Trait for &Type {...} //?

// such as
impl Delimiter for &str {...}

Additionally, if you intend to use both Type and &Type as implementers of Trait, for instance:

let x1: Vec<_> = StrSplit::new(haystack, MyOtherDelimiterFlavor::new(...)).collect();
let x2: Vec<_> = StrSplit::new(haystack, &MyOtherDelimiterFlavor::new(...)).collect(); 

would one then need to write redundant impl blocks, or is there some syntactic sugar for controlling this?

Thanks

It's actually fairly common, precisely to improve the ergonomics of using the trait as you indicate. In general, if you implement a trait that only takes &self it's pretty reasonable to implement the trait for &MyType, &mut MyType and Box<MyType>. If a trait method takes &mut self, skip &MyType. But of course, the downside is that now if the trait changes in the future, more breakage will ensure since your consumers expected to be able to transparently use & (or &mut).

Hi, curious how move and ownership works in the following line

s.find(self).map(|start| (start, start + self.len()))

I suppose the start need to be mutable? So, did we just move ownership of start?

https://gist.github.com/jonhoo/2a7fdcf79be03e51a5f95cd326f2a1e8#file-strsplit-rs-L41

No, start doesn't need to be mutable here as we never actually mutate it. Keep in mind that usize is Copy, so start + self.len() copies start and computes a new usize that is then returned.

thanks, as a rust beginner, is something confusing to spot whether a type implemnent copy trait or not. Thanks for making the one the best rust content on Youtube!!

Hi @jonhoo,

What is the difference between these two approach in next method

    fn next(&mut self) -> Option<Self::Item> {
        // if let Some(ref mut remainder) = self.remainder {
        //     if let Some(next_delim) = remainder.find(self.delimeter) {
        //         let until_delimeter = &remainder[..next_delim];
        //         *remainder = &remainder[(next_delim + self.delimeter.len())..];
        //         Some(until_delimeter)
        //     } else {
        //         self.remainder.take()
        //     }
        // } else {
        //     None
        // }

        if let Some(remainder) = self.remainder {
            if let Some(next_delim) = remainder.find(self.delimeter) {
                let until_delimeter = &remainder[..next_delim];
                self.remainder = Some(&remainder[(next_delim + self.delimeter.len())..]);
                Some(until_delimeter)
            } else {
                self.remainder.take()
            }
        } else {
            None
        }
    }

The compiler doesn't give any error and work as expected. Is it less efficient as I'm moving out and then reassigning, or some rust idiomatic I'm missing?

@MaxAsif Either of those are fine. They both work here because the type inside the Option in self.remainder is Copy, and so therefore you can pull it out in the initial if let Some and still be allowed to overwrite it further down. That wouldn't be the case if the type wasn't Copy (e.g., if it were a String). In that case you'd have to use the former (i.e., the commented-out code).

Something that might be worth noting here is that if the delimiter has length 0 (for example, an empty string), this will infinitely loop!

It will keep returning empty strings since the remainder never actually gets smaller in that case.

I'm not actually sure how that should be handled though, as it looks like "" patterns have non-standard behavior in the standard library: https://doc.rust-lang.org/std/primitive.str.html#impl-Pattern-for-%26str

For example:

fn main() {
    for s in "hello".split("") {
        println!("Result: \"{s}\"");
    }
}

Result: ""
Result: "h"
Result: "e"
Result: "l"
Result: "l"
Result: "o"
Result: ""

Playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5d009e96309f4f631bde4589d06f7cde

I don't think there is a trivially easy way to change the code in this gist to handle this off the top of my head, so I'll just leave this here for anyone curious!