-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement [OsStr]::join #96744
Implement [OsStr]::join #96744
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? @thomcc (rust-highfive has picked a reviewer for you, use r? to override) |
r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs |
@bors r+ |
📌 Commit 4fcbc53 has been approved by |
…piler-errors Rollup of 7 pull requests Successful merges: - rust-lang#96174 (mark ptr-int-transmute test as no_run) - rust-lang#96639 (Fix typo in `offset_from` documentation) - rust-lang#96704 (Add rotation animation on settings button when loading) - rust-lang#96730 (Add a regression test for rust-lang#64173 and rust-lang#66152) - rust-lang#96741 (Improve settings loading strategy) - rust-lang#96744 (Implement [OsStr]::join) - rust-lang#96747 (Add `track_caller` to `DefId::expect_local()`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
|
||
fn join(slice: &Self, sep: &OsStr) -> OsString { | ||
let Some(first) = slice.first() else { | ||
return OsString::new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use slice::split_first
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't know the function existed, thanks! Feel free to file a PR.
Ideally, one would make an optimized implementation like there is for str slices, but OsStr
is platform dependent in its representation as well as the invariants, so it's not as easy as just exporting that function from alloc, probably as perma unstable and #[doc(hidden)]
and then using it, at least not on unixes. It's a larger project and I wasn't sure if the PR was going to accepted at all, so I went with the simplest implementation I could think of, establishing a baseline that can later be improved. Maybe a good next step would be to use the join_generic_copy
function on Unix and fall back on the current implementation on other operating systems, but without benchmarking I don't know how much that is an improvement.
This PR changed the public stable API. |
@@ -1222,6 +1222,23 @@ impl OsStr { | |||
} | |||
} | |||
|
|||
#[unstable(feature = "slice_concat_ext", issue = "27747")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tracking issue #27747 was closed a while ago.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used the same tracking issue the other impl blocks for that trait have. The reason to close the tracking issue was because the feature is to be perma-unstable: #27747 (comment) . I'm not sure about changes in policy, but in the older times tracking issues for perma-unstable things would remain open indefinitely.
Willing to start one @m-ou-se ? If it doesn't make it through one can still revert the PR. |
Wow, I have no idea why I r+ed this! It wasn’t even assigned to me. I think I had confused it with another PR! 😰 |
Ugh, this is really concerning actually. I don't remember this PR at all (not my review or even the change itself)... The fact that it was r+ed on the 5th in the afternoon, is... very weird. That morning, I visited an urgent care clinic that morning (woke with mysterious+intense stomach pain), and... I basically came home, did a little work, then stopped and went to sleep through the whole time when the comment was made. Or... that's what I thought? I guess maybe I did stuff online that I... genuinely don't at all remember? :( Anyway, I'm sorry, I don't know what happened. But I don't expect this to be particularly reassuring... (it isn't to me). |
@thomcc it's sad to hear that you were in such a bad state of health. I hope you are doing better now. You were assigned initially but then later I made the r? command per advice of the bot, as this is indeed a change of the stable public API, which assigned someone else. I'm wondering what the way forward is for this change. |
Yeah that's normal. The confusing part is that I don't remember even seeing the PR, let alone reviewing it, and thought I was asleep during the time github says I make the review. I guess I'll change my password and such even though the circumstances definitely make it more likely that I did it (and just... lost that time that I thought I was sleeping 😓). I've put up a PR reverting it. I think the appropriate thing would be to resubmit and do it properly. In particular, this change is not obviously something we want. For example, I am not sure if I'm terribly sorry for the trouble here, and feel awful about causing it. |
Revert "Implement [OsStr]::join", which was merged without FCP. This reverts commit 4fcbc53, see rust-lang#96744. (I'm terribly sorry, and truly don't remember r+ing it, or even having seen it before yesterday, which is... genuinely very worrisome for me). r? `@m-ou-se`
Second attempt is in: #96881 |
Implement [OsStr]::join Implements join for `OsStr` and `OsString` slices: ```Rust 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 rust-lang#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`
Revert "Implement [OsStr]::join", which was merged without FCP. This reverts commit 4c460de02e132ef05e25888f0254a9eab894a223, see rust-lang/rust#96744. (I'm terribly sorry, and truly don't remember r+ing it, or even having seen it before yesterday, which is... genuinely very worrisome for me). r? `@m-ou-se`
Implements join for
OsStr
andOsString
slices:This saves one from converting to strings and back, or from implementing it manually.