Added slice_chars_from and slice_chars_to methods to StrSlice

[Kimundi]

They are occasional useful, and not having them is inconsistent to the byte-indice slice methods.

slice_chars, slice_chars_from and slice_chars_to are now implemented in terms of a common slice_chars_common function.

I also made the section headers in str.rs more visible, as they are they where to small to be really useful.

[huonw]

Hm, do we want this extra non-DRY code? I was thinking about this a little while ago, and though maybe making either or both arguments to .slice_chars Option<uint>'s might be better since .slice_chars is not super useful itself (directly manipulating non-grapheme characters; is O(n); etc.) and so these specialised versions are even less so.

Furthermore, having it explicitly in the types hopefully makes someone less like to do s.slice_chars(10, Some(s.char_len())) rather than just s.slice_chars(10, None).

[huonw]

(At the very least, I think an internal helper function of that form would be an antidote to repeating similar code 3 times.)

[Kimundi]

Yeah, at the very least it could all live in a internal helper, that's true.

In a way, this is only a temporary API improvement anyway, as the string API still needs some major overhauls, and decisions (For example #9391 and #9440)

slice_from and slice_to (including these new char variants) are incomplete anyway in that they take an index starting from the front, while taking one from the back can be useful too, and at least for chars and grapheme clusters is faster than doing char_len() - n.

I think the most general solution would be to factor out the the ability to view a string as a sequence of bytes, a sequence of chars, and a sequence of grapheme clusters, and the provide an identical API for those three:

"äbc".as_char_str().slice_from(1) == "bc"
"äbc".as_char_str().slice_to(1) == "ä"
"äbc".as_char_str().reverse_slice_from(1) == "äb"
"äbc".as_char_str().reverse_slice_to(1) == "c"

"äbc".as_utf8_str().slice_from(2) == "bc"
"äbc".as_utf8_str().slice_to(2) == "ä"
"äbc".as_utf8_str().reverse_slice_from(1) == "äb"
"äbc".as_utf8_str().reverse_slice_to(1) == "c"

[Kimundi]

I pushed a commit that moves the common code into one function

[huonw]

I think this would be clearer if the _ arm wasn't hiding at the end (also the , is unnecessary).

[Kimundi]

Addressed the stylistic issue

[alexcrichton]

Closing due to a lack of activity.

I'm worried that if we start adding methods for chars as well as bytes then are we also going to have to start adding methods for graphemes as well? I don't think that this PR should fundamentally not be merged, but we need to give the str API careful thought before adding functions like this.