Tracking Issue for `string_replace_in_place`

Feature gate: #![feature(string_replace_in_place)]

This is a tracking issue for String::replace_first and String::replace_last

Public API

// alloc::string

impl String {
    pub fn replace_first<P: Pattern>(&mut self, from: P, to: &str);
    pub fn replace_last<P: Pattern>(&mut self, from: P, to: &str)
        where for<'a> P::Searcher<'a>: ReverseSearcher<'a>;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: rust-lang/libs-team#506
• Implementation: #134316
• Final comment period (FCP)^1
• Stabilization PR

Unresolved Questions

(copied from ACP "Alternatives" section)

• The method names could include in_place or similar, to distinguish them from replace/replacen methods on str that are not in-place. There is already String::replace_range though, that is in-place but does not explicitly indicate this in its name.

• @tgross35 mentioned on the implementation PR that it would make sense for there to also be an in-place str::replace alternative. If these are named replace_first_in_place, that would match nicely with a possible String::replace_in_place and/or String::replacen_in_place that do what str::replace/str::replacen do, but in-place.

• Users could use the more general str::replacen if allocation is not a bottleneck, or if the needle and replacement are not the same length and copying the haystack to a new allocation is faster than shuffling data around in one allocation.

• Users could implement these manually in terms of existing String/str APIs (the implementation uses only the existing safe, stable APIs str::(r)match_indices and String::replace_range).

• These could be fn(self) -> Self instead of fn(&mut self). This would make it difficult to perform on a mutably borrowed String: *string = std::mem::take(string).replace_first(...); vs string.replace_first(...);

• These could be fn(&mut self) -> &mut Self to allow chaining multiple calls, but this might be less clear that it does not return a new String allocation.

• These could return a bool indicating whether a match was found, avoiding the need to search twice https://github.com/rust-lang/rust/issues/147949#issuecomment-3446645296