split() should document the behavior around adjacent separators, particularly at the start of the string

[nikomatsakis]

It's not clear to me if this is the expected behavior or not, but this program:

fn main() {
    let x = "    a  b c".to_string();
    let d: Vec<_> = x.split(' ').collect();
    println!("{:?}", d);
}

yields:

["", "", "", "", "a", "", "b", "c"]

whereas I expected:

["a","b","c"]

If the current behavior is expected, it should be more clearly documented, at minimum.

cc @Kimundi

[nikomatsakis]

That said, it does seem inconsistent to me? For example, four leading spaces yields four empty entries, but two intermediate spaces yield one empty entry, and one intermediate space yields no empty entries.

[Veedrac]

There are two reasonable behaviours I see. One is to split around padding, to get ["a", "b", "c"]. The other is to split around delimiters, eg. ",12,,34".split(',') → ["", "12", "", "34"]. This would keep the ends of the string, even if empty.

[bluss]

It is certainly expected by the implementors, this is the way it has been since introduction of .split() I believe. Since it's stable, I guess it's a documentation issue

Replace each space with a splitting point and it seems consistent

"    a  b c"
"||||a||b|c"

=> "", "", "", "", "a", "", "b", "c"

@nikomatsakis You're not taking into account the string that precedes the first separator I guess. It's empty in this case.

[bluss]

FWIW, Python does the same thing

>>> "    a  b c".split(' ')
['', '', '', '', 'a', '', 'b', 'c']

Both Rust and Python can filter the list or iterator just fine, but it's slightly simpler in Python since an empty string is a falseish value.

[nikomatsakis]

@bluss yes, ok, that makes sense (I did not, it's true, consider the "empty string" at the beginning.)

I don't particularly like this behavior -- I've always found it annoying in Python too :) -- but yes I agree it's a doc issue, not a bug.

[Kimundi]

@bluss basically said all I'd say already. So yeah, I guess the docs could be improved a bit?

[nagisa]

That said, it does seem inconsistent to me? For example, four leading spaces yields four empty entries, but two intermediate spaces yield one empty entry, and one intermediate space yields no empty entries.

.split(x).connect(x) should be an identity function, which is how it is consistent.

[Veedrac]

@nagisa This doesn't seem to actually be the case. The number of leading spaces seems to match the number of empty entries. Eg.

println!("{:?}", " a  b c".to_owned().split(' ').collect::<Vec<_>>());
#>>> ["", "a", "", "b", "c"]

As such, the requirement seems to hold.

[nagisa]

@nagisa This doesn't seem to actually be the case.

I don’t understand what you’re trying to say here, because split(x).connect(x) is an identity function (well, yeah, you have to collect it in between, etc; but that’s not the point):

" a  b c" == " a  b c".to_owned().split(" ").collect::<Vec<_>>().connect(" ")
(20:39:06) playbot: (notice) true

[Veedrac]

Sorry, I thought by saying "should be" you were implying that it wasn't - I was pointing out that it is consistent. Nvm then, we agree.