-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Stabilize path_file_prefix
feature
#144870
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
Conversation
This comment has been minimized.
This comment has been minimized.
8235756
to
0fc453f
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment has been minimized.
This comment has been minimized.
0fc453f
to
4c4b8b2
Compare
FWIW there seems to be an outstanding concern #86319 (comment) |
I saw that but it seems like it's about adding another function, right? Or they want to make this new function a part of this stabilizaton? |
cc @the8472 (I don't know) |
I was suggesting to make this part of this function. Alas, nobody responded to that suggestion. |
We can open FCP to add this as an additional function to this and make it part of this feature in this PR, because I also think that this is better to return both parts This wasn't fully discussed at the time, so I think it's worth addressing now, and I believe it's better late than never |
@rustbot label +I-libs-api-nominated As noted, FCP completed at #86319 (comment) but there was a concern raised (not via rfcbot) #86319 (comment). Does this change anything for the FCP result? (The iterator idea suggested at #86319 (comment) has a ton of +1s, and I believe would resolve the concern). |
…iplett add code example showing that file_prefix treats dotfiles as the name of a file, not an extension This came up in a libs-api meeting while we were reviewing rust-lang#144870
…iplett add code example showing that file_prefix treats dotfiles as the name of a file, not an extension This came up in a libs-api meeting while we were reviewing rust-lang#144870
After some discussion with the libs team I'm withdrawing my concern since people consider this feature useful on its own even if an iteration version existed. |
@bors r+ rollup |
Rollup of 11 pull requests Successful merges: - #143467 (Add ASCII-related methods from `u8` and `MIN`/`MAX` to `core::ascii::Char`) - #144519 (Constify `SystemTime` methods) - #144642 (editorconfig: don't trim trailing whitespace in tests) - #144870 (Stabilize `path_file_prefix` feature) - #145269 (Deprecate RUST_TEST_* env variables) - #145274 (Remove unused `#[must_use]`) - #145289 (chore(ci): upgrade checkout to v5) - #145303 (Docs: Link to payload_as_str() from payload().) - #145308 (Adjust documentation of `dangling`) - #145320 (Allow cross-compiling the Cranelift dist component) - #145325 (Add `cast_init` and `cast_uninit` methods for pointers) r? `@ghost` `@rustbot` modify labels: rollup
Thank you all. So should I go ahead and make a tracking issue for the iterator method that gives you all parts of the Path? |
I don't think it is accepted yet, so it needs to be proposed first. If you have an API in mind, open an ACP issue template at https://github.com/rust-lang/libs-team/issues to do so. |
This stabilises
Path::file_prefix
, following the FCP in tracking issue(FCP ended almost a year ago, so if it's needed for proccess we could rerun it)
Closes: #86319