Tracking issue for `str_char` stabilization

[aturon]

The str type offers a number of char-oriented methods, many of which can be replaced by uses of char_indices.

It's not clear how widely used these methods are, or whether there are significant downsides over using char_indices. This API area needs a comprehensive re-evaluation.

cc @SimonSapin

[murarth]

This may be obvious, but I just want to point out that is_char_boundary is much more efficient than a solution involving iteration over char_indices. If nothing else under this feature gate is stabilized, I think at least this should method should be.

[SimonSapin]

I’ve used str::is_char_boundary in low-level string manipulation: rust-lang/rfcs#1432. In this case I’d like this functionality to move into std where stability is not a problem, but the fact remains that is_char_boundary is important in unsafe code dealing with strings.

Now, most (all?) of its uses are inside assert!, which is possibly to do in stable Rust by relying on the side effect of some other operation. For example, s[..i]; is equivalent to assert!(s.is_char_boundary(i)); but it’s much less self-explanatory. It definitely needs a comment.

I’d like to nominate is_char_boundary for stabilization. It’s needed internally anyway, so it’s not like it has extra maintenance cost.

(I care less about the other str_char methods. I think they predate and are largely made obsolete by external iterators.)

[huonw]

Some discussion about CharRange on #9387.

[aturon]

Nominating for discussion -- need a direction here.

[dhardy]

I found a use for is_char_boundary recently, in order to implement a variant of truncate:

fn truncate_at_boundary<'a>(s: &'a str, len: usize) -> &'a str {
    let mut len = min(len, s.len());
    while !s.is_char_boundary(len) { len -= 1; }
    &s[0..len]
}

on play.rust-lang.org

[bluss]

is_char_boundary is very useful, as soon as you implement your own low level string utils. I've replicated in stable rust for use as well.

[alexcrichton]

Unfortunately the libs team didn't get a chance to talk about this in terms of stabilization for 1.8, but I'm going to leave the nominated tag as I think we should chat about this regardless.

[alexcrichton]

The libs team discussed this during triage today, and the conclusion was:

• It seems prudent to stabilize is_char_boundary (definitely seems desired at least)
• We may be able to deprecate all other methods, they're all expressible in terms of slicing an iterators, and there doesn't seem to be much of a burning desire to keep them!

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period 🔔

Specifically, the libs team would like to:

• Stabilize is_char_boundary
• Deprecate char_range_at - slicing plus chars() plus len_utf8 should suffice
• Deprecate char_range_at_reverse - slicing plus chars().rev() plus len_utf8 should suffice
• Deprecate char_at - slicing plus chars() should suffice
• Deprecate char_at_reverse - slicing plus chars().rev() should suffice
• Deprecate slice_shift_char - using chars() should suffice (plus the Chars::as_str method)

[aturon]

Some more detail from the meeting:

Clearly the deprecations here represent an ergonomic regression, but the general feeling is that most of these are quite niche methods, and as long as std can express them efficiently, external crates can build up whatever ergonomic wrappers are needed.

If you disagree with this characterization, please speak up during FCP!

[bluss]

@alexcrichton I think you mean len_utf8 which is a handy lil method.

str docs will improve when these unstable ones are gone, less noise!

[alexcrichton]

Oops yes indeed!

[thijsc]

👍 On the deprecations. I was actually just bitten by char_at because I did not properly understood how it worked. My assumption was that the position you provide was for the position of the character, while actually of course it's the position of the byte you're trying to use as the first byte of a character. To me this was counterintuitive.

I think we should encourage using char_indexes as much as possible, that provides an actually safe api. If you know what you're doing the slicing approach seems fine.

[BurntSushi]

Also 👍 on the deprecations. I do a ton of work with strings and I can't recall ever feeling like I was missing them.

[alexcrichton]

The libs team discussed this during triage yesterday and the conclusion was to move forward with the previously proposed plan.