Tracking Issue for string_replace_in_place (original) (raw)

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: In-place String::replace_first and String::replace_last libs-team#506
• Implementation: Add String::replace_first and String::replace_last #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.

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩