tracking issue for strip_prefix, strip_suffix for str

[Dylan-DPC-zz]

Cc @KodrAus

Will fill the content later. Creating this so that #66735 can be merged and tracked.

[tesuji]

The code generated by str::strip_prefix is really complicated and inefficient.
Godbolt link: https://rust.godbolt.org/z/AnEoHH
Should we add strip_prefix / strip_suffix method directly to Pattern or Searcher trait?

[CryZe]

Oof that does indeed look pretty bad.

[benesch]

I whipped up that fix here: #69784

Not sure if it's actually the ideal fix, but figured it would be a good point to launch the discussion from.

[benesch]

Ok, the code should be far more optimized now. What remains to be done? The main issue description has yet to be filled in. 😄

[lights0123]

On some criterion benchmarks that I did, I'm seeing that

fn strip_suffix(input: &str) -> &str {
	input.strip_suffix(char::is_whitespace).unwrap_or(input)
}

is much faster than trim_end, at least for newlines only. Is this only because I'm stripping off a very small amount of text, or is this function more optimized than trim_end (assuming that I didn't screw something up)? See "Standard strip suffix" versus "Standard trim end", with "unix" having the input of "50\n" and "win" being "50\r\n":

[benesch]

Ah, yeah, looks the optimizations I made to strip_prefix/strip_suffix in #69784 are optimizations that don't exist for trim_end:

rust/src/libcore/str/mod.rs

Lines 4137 to 4148 in 20fc02f

	pub fn trim_end_matches<'a, P>(&'a self, pat: P) -> &'a str
	where
	P: Pattern<'a, Searcher: ReverseSearcher<'a>>,
	{
	let mut j = 0;
	let mut matcher = pat.into_searcher(self);
	if let Some((_, b)) = matcher.next_reject_back() {
	j = b;
	}
	// SAFETY: `Searcher` is known to return valid indices.
	unsafe { self.get_unchecked(0..j) }
	}

I wonder if trim_end_matches could be reimplemented as a loop over strip_suffix_of...

By the way, since I'm here, @Dylan-DPC (or anyone else on the Rust team), what remains to be done for this issue?

[Dylan-DPC-zz]

By the way, since I'm here, @Dylan-DPC (or anyone else on the Rust team), what remains to be done for this issue?

If you want to change the implementation this is a good time. Else, the thing left is stabilisation with the libs team approving it (if needed) but i'd wait for some time to check if there are any other issues.

[benesch]

The implementation is now faster than the existing similar stable functions trim_start and trim_end, so I think we're in a good spot implementation wise. Would you be able to add a note about the progress and when we expect to start the stabilization discussion in the issue description? (Or whatever normally goes in there?)