Tracking Issue for os_str_display

[riverbl]

Feature gate: #![feature(os_str_display)]

This is a tracking issue for the OsStr::display method.

Public API

// std::ffi

pub mod os_str {
    pub struct Display<'a> { /* private fields */ }
}

impl OsStr {
    pub fn display(&self) -> os_str::Display<'_>;
}

Steps / History

• ACP: ACP: Add OsStr::display (similar to Path::display) libs-team#326
• Implementation: Add display method to OsStr #120051
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[ijackson]

I'm concerned about the name. I think OsStr::to_string_lossy is the better precedent. Path has just display and I think this was a mistake.

These methods are really only suitable for use in diagnostics. Places where the stringlike thing is transformed for further use must necessarily either give up on handling invalid unicode (so should use a fallible method) or do something more complicated and awkward.

[ijackson]

(Worst case behaviour from inappropriate use of these methods is modifying the wrong file.)

[riverbl]

I'm concerned about the name. I think OsStr::to_string_lossy is the better precedent. Path has just display and I think this was a mistake.

Path has both to_string_lossy and display. OsStr already has to_string_lossy, which works in the same way as Path::to_string_lossy. This issue is for adding OsStr::display, which would work in the same way as Path::display.

These methods are really only suitable for use in diagnostics. Places where the stringlike thing is transformed for further use must necessarily either give up on handling invalid unicode (so should use a fallible method) or do something more complicated and awkward.

I've encountered situations where OsStr::display would be useful for displaying a potentially non Unicode file name to the user (example). In these cases, the lossy Unicode representation of the OsStr is not used beyond being displayed.