Implement [OsStr]::join

[est31]

Implements join for OsStr and OsString slices:

    let strings = [OsStr::new("hello"), OsStr::new("dear"), OsStr::new("world")];
    assert_eq!("hello dear world", strings.join(OsStr::new(" ")));

This saves one from converting to strings and back, or from implementing it manually.

This PR has been re-filed after #96744 was first accidentally merged and then reverted.

The change is instantly stable and thus:

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

cc @thomcc @m-ou-se @faptc

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

impl<S: Borrow<OsStr>> alloc::slice::Join<&OsStr> for [S] {
    type Output = OsString;
    …
}

This closely mirrors the same impl that exists for str join:

// since 1.3.0
impl<S: Borrow<str>> Join<&str> for [S] {
    type Output = String;
    …
}

The new impl makes <[_]>::join usable with OsStr. It's basically a convenience around the already existing OsString::push.

One thing to be aware of is the platform-specific behavior, which is the same as for push:

• On cfg(unix), joining OsStrs holding arbitrary bytes will just concat the bytes. It's possible that joining multiple non-UTF-8 strings produces a UTF-8 string.

• On cfg(windows), there is some fancier logic in push that will look for a lone leading surrogate at the end of the first string and a lone trailing surrogate at the front of the second string, and if so, combine them into a single codepoint. So it's not just a matter of naively concating WTF-8 bytes.

The Windows one makes a lot of sense to me in the case of join(OsStr::new("")). For the case of nonempty separator, it's a little weird that surrogates in the separator can complete codepoints in the slice, but probably also fine.

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[joshtriplett]

look for a lone leading surrogate at the end of the first string and a long trailing surrogate at the end of the second string

I think this should say "at the start of the second string"?

[est31]

@joshtriplett yeah it's done that way in the push_wtf8 function.

[dtolnay]

@bors r+

[bors]

📌 Commit cb60e70 has been approved by dtolnay

[bors]

⌛ Testing commit cb60e70 with merge 989b806...

[bors]

☀️ Test successful - checks-actions
Approved by: dtolnay
Pushing 989b806 to master...

[rust-timer]

Finished benchmarking commit (989b806): comparison url.

Instruction count

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-1.1%	-1.1%	3
All 😿🎉 (primary)	N/A	N/A	0

Max RSS (memory usage)

Results

• Primary benchmarks: 😿 relevant regression found
• Secondary benchmarks: 🎉 relevant improvement found

	mean1	max	count2
Regressions 😿 (primary)	2.1%	2.1%	1
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-3.3%	-3.3%	1
All 😿🎉 (primary)	2.1%	2.1%	1

Cycles

Results

• Primary benchmarks: 🎉 relevant improvements found
• Secondary benchmarks: no relevant changes found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-2.4%	-2.8%	2
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	-2.4%	-2.8%	2

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³