Tracking Issue for ASCII trim functions on byte slices

[dbrgn]

Feature gate: #![feature(byte_slice_trim_ascii)]

This is a tracking issue for ASCII trim functions on byte slices.

Public API

The feature adds three new methods to byte slices ([u8]):

• const fn trim_ascii_start(&self) -> &[u8]: Remove leading ASCII whitespace
• const fn trim_ascii_end(&self) -> &[u8]: Remove trailing ASCII whitespace
• const fn trim_ascii(&self) -> &[u8]: Remove leading and trailing ASCII whitespace

For deciding what bytes to treat as whitespace, u8::is_ascii_whitespace is used. See the linked docs for more details.

Examples:

assert_eq!(b" \t hello world\n".trim_ascii_start(), b"hello world\n");
assert_eq!(b"\r hello world\n ".trim_ascii_end(), b"\r hello world");
assert_eq!(b"\r hello world\n ".trim_ascii(), b"hello world");

Steps / History

• Implementation: core: Implement ASCII trim functions on byte slices #93686
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should the methods be made const by using a pattern matching approach instead of indexing?
• Should corresponding methods be added to str as well?

[nagisa]

If we're adding ascii variants to [u8], we should also add equivalent operations to str at the same time. I feel this is pretty important because otherwise the APIs made available by libstd can come across like a grab bag of random stuff.

It seems reasonable enough to want to trim ASCII whitespace from a &str too (there's already split_ascii_whitespace), and so today one would resort to trim_matches or with this implementation they could convert between [u8] and str. The need to do latter can come across as a particularly frustrating API surface omission.

---

naming bikeshed: might trim_ascii_start and trim_ascii_end be more consistent with other functions already in libstd? There's some prior art in naming of str::split_ascii_whitespace vs str::split_whitespace, {char,u8}::is_ascii_* vs {char,u8}::is_* etc.

[dbrgn]

If we're adding ascii variants to [u8], we should also add equivalent operations to str at the same time. I feel this is pretty important because otherwise the APIs made available by libstd can come across like a grab bag of random stuff.

Since str is validated unicode, trim_start and trim_end could be used, which uses the unicode definition of whitespace. On the other hand, we have char::is_ascii_whitespace, so it should be fairly easy to add these functions to string slices as well. However, I don't really see a use case for this. Why would someone use trim_start_ascii over trim_start?

naming bikeshed: might trim_ascii_start and trim_ascii_end be more consistent with other functions already in libstd? There's some prior art in naming of str::split_ascii_whitespace vs str::split_whitespace, {char,u8}::is_ascii_* vs {char,u8}::is_* etc.

Yes, you have a point there! There's also str::to_lowercase and str::to_ascii_lowercase. I will update the proposal and implementation PR.

[Kage-Yami]

On the other hand, we have char::is_ascii_whitespace, so it should be fairly easy to add these functions to string slices as well. However, I don't really see a use case for this. Why would someone use trim_start_ascii over trim_start?

Naively (without knowing the internals at all), I could think of "performance" as a reason.

That being said, does this unresolved question really need to block this from being stabilised? After all, it's specifically about &[u8], not slices in general. If we can agree to that, then what's stopping this from proceeding to FCP? (I'm having trouble finding documentation for the process for tracking issue FCPs, could only find something for RFCs...)