Tracking issue for str::slice_mut_unchecked

[alexcrichton]

This is a tracking issue for the unstable str_slice_mut feature in the standard library. The major open question here is to what extent we want to support &mut str in the standard library. Currently the support is likely falling short in a number of &str vs &mut str methods, and it's unclear to what extent we want to provide the full suite of methods operating over &mut str. We may wish to just punt entirely on these suites of methods. Definitely needs a decision!

cc @SimonSapin

[SimonSapin]

Maybe this and #27809 should be decided together with the overall fate of &mut str.

Although these methods are rarely needed and can be emulated unsafely with String::as_mut_vec there isn’t any real issue with them, is there?

[alexcrichton]

Nominating for 1.5 resolution

[SimonSapin]

it's unclear to what extent we want to provide the full suite of methods operating over &mut str.

I don’t think there are that many methods we could add to &mut str. Mutating while preserving the UTF-8 invariant and the length is fairly limited.

I’d be OK with deprecating this and reverting #27809 to OwnedAsciiExt::into_ascii_lowercase(String) -> String. That would not be a loss of generality as the &mut String methods could be simulated with mem::replace.

[alexcrichton]

This issue is now entering its cycle-long FCP for stabilization in 1.5

[alexcrichton]

@SimonSapin even if we went back to into_ascii_lowercase I'd be fine with this still existing, it follows existing patterns quite well and isn't really a burden to maintain.

[alexcrichton]

The libs team discussed this today and the decision was to stabilize.