@bmulvihill This is excellent, thank you!

I was thinking about this and we'll probably need different iterator implementation for each kind of argument that you can pass: no arguments (split by whitespace), char (the one you already implemented), string and regex. What do you think?

@asterite I added an iterator for each type of split, and also one for an Empty separator split, which is shared logic for the String and Regex splits when no separator is provided.

Thanks!

@asterite Any feedback on this? I tried to keep the iterator implementations similar to their split counterparts. Would you like me to split this out into different PRs for easier review?

Thanks!

@bmulvihill Thank you for this!

I did have a chance to review it, but now I'm not 100% convinced this is a good idea. Now that there's code for this, I took the time to benchmark it, both in terms of speed and memory. It only starts to make a difference for really big strings.

Since the whole idea of iterators are to reduce memory allocation, one wouldn't have a huge string in memory in the first place. For example, I can imagine one would iterate a File line by line, or something like that. And then, lines aren't usually very long, and the difference between split and each_split is not big, or even noticeable, because one still needs to allocate memory for the iterator itself.

In short, I'm not sure it's worth adding so much code for this when the current split is probably enough.

Note that I couldn't have come to this conclusion without having code to check this. I'm not convinced this PR should be rejected, I should probably consult this with others and see what they think. For example Rust has iterators for split.