Tracking Issue for `CStr::display`

[tamird]

Feature gate: #![feature(cstr_display)]

This is a tracking issue for the CStr::display API.

Implement Display for CStr and CString. The implementation would be the same as for the ByteStr and ByteString types.

Public API

I'm abusing the API section here to include the whole implementation, as it is very simple.

impl CStr {
    pub fn display(&self) -> impl fmt::Display {
        crate::bstr::ByteStr::from_bytes(self.to_bytes())
    }
}

Steps / History

Motivation and discussion is elaborated in the ACP.

2025-02-27: ACP created by @Darksonn.
2025-04-17: ACP accepted by @BurntSushi.
2025-04-17: tracking issue created.
2025-04-29: @rust-lang/libs-api team decided against implementing Display for CStr in favor of adding a display method like on OsStr and Path.
2025-05-24: implementation updated to add CStr::display.

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: add CStr::display #139994
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[tamird]

Closing per https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html:

Changes that are instantly stable (e.g. trait implementations on stable types) do not need a tracking issue. However, such changes need extra scrutiny as there will be no chance to adjust the API during an unstable period.

The PR is #139994,