Closed KSXGitHub closed 7 months ago
I buy it.
@BurntSushi Apologies for not understanding the process. But you just simultaneously added ACP-accepted
label and close this issue with no apparent follow up (I didn't see any PR). Does this mean it is rejected or accepted? If it is accepted, how will the feature be implemented and by whom?
It's accepted. Now anyone can submit a PR adding this as an unstable API. I don't believe there is any specific assignment to a particular person to implement it.
how will the feature be implemented and by whom?
Often it's the person who opened the ACP as they are most invested in the feature existing 😉
Proposal
Problem statement
I need to convert an owned
PathBuf
into an ownedString
(if it is valid UTF-8). I would need to writepath_buf.to_os_string().into_string()
. Since aPathBuf
is just a wrapper ofOsString
, I find having to typeinto_os_string
unnecessary.Internal discussions: https://internals.rust-lang.org/t/why-doesnt-the-into-string-method-be-available-directly-under-pathbuf-even-though-it-already-exists-in-osstring/19935
Motivating examples or use cases
Solution sketch
Just add the following method:
Alternatives
There are other "direct" methods such as
to_str
orto_string_lossy
but they all do unnecessary clone and allocation for owned types, so the only real alternative isinto_os_string
.Links and related work
What happens now?
This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
Second, if there's a concrete solution: