Tracking Issue for PathBuf::add_extension and Path::with_added_extension

Feature gate: #![feature(path_add_extension)]

This is a tracking issue for

PathBuf::add_extension
Path::with_added_extension

Public API

impl PathBuf {
    pub fn add_extension<S: AsRef<OsStr>>(&mut self, extension: S) -> bool { ... )
}

impl Path {
    pub fn with_added_extension<S: AsRef<OsStr>>(&self, extension: S) -> PathBuf { ... }
}

Steps / History

ACP: impl PathBuf::add_extension and Path::with_added_extension libs-team#368
Implementation: impl PathBuf::add_extension and Path::with_added_extension #123600
Final comment period (FCP)
Stabilization PR

Implementation history

Unresolved Questions

None yet.

Footnotes

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

This would be really awesome honestly, just encountered an issue where this would have made my life easier.

Hoping this becomes available in stable soon. Such a nice QoL api.

This new API is awesome!

But I think It would be better to rename (deprecate old and add new name) existing API with_extension with with_replaced_extension and set_extension with replace_extension along with this feature.
I feel existing function with_extension and set_extension is confusing if it will replace or append extension.

Actually I mistakenly used with_extension as with_added_extension and we can see some such case in rust form like this.

But I think It would be better to rename (deprecate old and add new name) existing API with_extension with with_replaced_extension and set_extension with replace_extension along with this feature.

I agree with the rename however we can only do that with a new edition (since with_extension is stable) right? And that might take a few more years. That should not block the stabilization of the added API.

I don't think edition change is required since we don't have to actually rename the function.
We can introduce with_replaced_extension in some version, and deprecate with_extension in following or later version.

I think there are some cases that deprecating without edition change like deprecate _ms functions with Duration parameter variants.

@rfcbot

Starting an FCP to stabilize this:

@rfcbot merge

@joshtriplett

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

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.

Rollup merge of rust-lang#140163 - thaliaarchi:pathbuf-validate-exten…

Stabilization PR: #145209

IMO it's still a mistake to stabilize the panicking version of with_added_extension(). I don't think anyone has disagreed that:

with_extension() is a confusing name that should be changed to with_replaced_extension().
It's preferable to return Result<> instead of panicking.

If we were to deprecate with_extension() and add with_replaced_extension() -> Result<> then we could also have with_added_extension() -> Result<> and it wouldn't be inconsistent. (It wasn't explicitly stated but I assume inconsistency with with_extension() was reason to copy its mistake to with_added_extension().)

If we stabilise this PR I think we're probably stuck with this sub-par API forever.

I suggest:

Add with_replaced_extension() -> Result<>
Change with_added_extension() to return Result<>
Deprecate with_extension(), because it's confusingly named and has surprising panics.

I'd be happy to implement this if it would be accepted.

I don't think anyone has disagreed that:

People (including libs-api members) very much have disagreed, several times, in the above discussion and in meetings reported in comments on this issue. Just not in response to your comment specifically because very similar points were raised by others before. That doesn’t mean the team can’t change its mind now, but it’s not new information either.

Rollup merge of rust-lang#145209 - hanna-kruppe:path_add_extension, r…

Unrolled build for #145209

Rollup merge of #145209 - hanna-kruppe:path_add_extension, r=tgross35

Rollup merge of rust-lang#145209 - hanna-kruppe:path_add_extension, r…

Navigation Menu

Repository navigation

Tracking Issue for PathBuf::add_extension and Path::with_added_extension #127292

Public API

Steps / History

Implementation history

Unresolved Questions

Footnotes

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for PathBuf::add_extension and Path::with_added_extension #127292

Description

Public API

Steps / History

Implementation history

Unresolved Questions

Footnotes

Activity

MordechaiHadad commented on Aug 8, 2024

dilawar commented on Sep 22, 2024

anatawa12 commented on Oct 16, 2024

yara-blue commented on Dec 22, 2024

anatawa12 commented on Dec 23, 2024

joshtriplett commented on Jan 7, 2025

rfcbot commented on Jan 7, 2025

27 remaining items

hanna-kruppe commented on Aug 10, 2025

Timmmm commented on Aug 10, 2025

hanna-kruppe commented on Aug 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions