Closed riverbl closed 8 months ago
Path
's display actually wraps the private OsStr::display
which could probably be exposed pretty easily. Probably move Display
to std::ffi
and make std::path::Display
a type alias for it.
CStr
needs something like this too but will need a different implementation.
We discussed this in the libs-api meeting today. We're happy to accept this ACP, and discussed some of the finer API details:
OsStr::display
should be in std::ffi::os_str::Display
(the os_str
module should become public, OsStr
should be re-exported into std::ffi
from there).std::path::Display
should stay as a separate type, which wraps std::ffi::os_str::Display
.Feel free to open a tracking issue and open a PR to rust-lang/rust to add it as an unstable feature.
Proposal
Problem statement
Sometimes it is desirable to display an
OsStr
with invalid Unicode sequences replaced with�
. Currently, the most obvious way to do this is withOsStr::to_string_lossy
, however this incurs an allocation and additional copy when theOsStr
contains invalid Unicode. It would be useful to have an obvious and efficient way to do this.Motivating examples or use cases
Lapce has a few cases of needing to display an
OsStr
, for example here:Solution sketch
Add a
display
method toOsStr
, similar to the existingPath::display
method. The method would return a type that references theOsStr
and implementsfmt::Display
.The implementation could reuse the logic currently used for
Path::display
. See the most recent commit on https://github.com/riverbl/rust/tree/os-str-display for an example implementation.Alternatives
OsStr::to_string_lossy
allows displaying anOsStr
, but is less efficient.OsStr
implementsAsRef<Path>
, soPath::display
could be used and would be just as efficient as this new method. The main issue I see with usingPath::display
is that it is confusing to anyone reading the code that anOsStr
, the contents of which may not relate to a path, is being converted to aPath
before being displayed.A crate could provide this functionality, either using
Path::display
or a custom implementation on top ofOsStr::as_encoded_bytes
.Links and related work
Path::display
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: