ACP: Add OsStr::display (similar to Path::display)

[riverbl]

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 with OsStr::to_string_lossy, however this incurs an allocation and additional copy when the OsStr 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:

let (svg, color) = config.file_svg(&path);
(
    svg,
    color,
    format!(
        "{} (Diff)",
        path.file_name()
            .unwrap_or_default()
            .to_string_lossy()
    ),
    is_pristine,
)

Solution sketch

Add a display method to OsStr, similar to the existing Path::display method. The method would return a type that references the OsStr and implements fmt::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 an OsStr, but is less efficient.

OsStr implements AsRef<Path>, so Path::display could be used and would be just as efficient as this new method. The main issue I see with using Path::display is that it is confusing to anyone reading the code that an OsStr, the contents of which may not relate to a path, is being converted to a Path before being displayed.

A crate could provide this functionality, either using Path::display or a custom implementation on top of OsStr::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):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[tgross35]

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.

[Amanieu]

We discussed this in the libs-api meeting today. We're happy to accept this ACP, and discussed some of the finer API details:

• The type returned by 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.