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.)
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.
Feature gate:
#![feature(string_replace_in_place)]This is a tracking issue for
String::replace_firstandString::replace_lastPublic API
Steps / History
(Remember to update the
S-tracking-*label when checking boxes.)String::replace_firstandString::replace_lastlibs-team#506String::replace_firstandString::replace_last#134316Unresolved Questions
(copied from ACP "Alternatives" section)
The method names could include
in_placeor similar, to distinguish them fromreplace/replacenmethods onstrthat are not in-place. There is alreadyString::replace_rangethough, 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::replacealternative. If these are namedreplace_first_in_place, that would match nicely with a possibleString::replace_in_placeand/orString::replacen_in_placethat do whatstr::replace/str::replacendo, but in-place.Users could use the more general
str::replacenif 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/strAPIs (the implementation uses only the existing safe, stable APIsstr::(r)match_indicesandString::replace_range).These could be
fn(self) -> Selfinstead offn(&mut self). This would make it difficult to perform on a mutably borrowedString:*string = std::mem::take(string).replace_first(...);vsstring.replace_first(...);These could be
fn(&mut self) -> &mut Selfto allow chaining multiple calls, but this might be less clear that it does not return a newStringallocation.Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩