Tracking Issue for `const_cstr_methods`

[WaffleLapkin]

Feature gate: #![feature(const_cstr_methods)]

This is a tracking issue for CStr methods as const functions.

Public API

// core::ffi

impl CStr {
    // feature(const_cstr_methods)
    pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError>;
    pub const fn to_bytes(&self) -> &[u8];
    pub const fn to_bytes_with_nul(&self) -> &[u8];
    pub const fn to_str(&self) -> Result<&str, str::Utf8Error>;
}

// Note that those methods are stable, they are only unstable as `const` fn

Steps / History

• Implementation: constify some CStr methods #100291
• Final comment period (FCP)¹
• Stabilization PR Stabilize const_cstr_methods #107624

Unresolved Questions

• None yet.

Footnotes

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

[tgross35]

@WaffleLapkin are any of these uncontroversial enough that you'd be comfortable const stabilizing them?

For #107429 I had to mark some of the memchr functions const stable, and the methods here largely have the same const dependencies. So, at least a subset of these could probably go const stable in the same release.

[WaffleLapkin]

@tgross35 I personally think that all of these are uncontroversial and I'd be very comfortable stabilizing them, however I do not posses the power to do so. Stabilizing library APIs is a prerogative of T-libs-api.

[tgross35]

Rightieo, I just was wondering if you had any bad feeling that any of them would be unmaintainable as const.

I think the FCP could take place on the PR since this is quite small, similarly to #107429. Would you like to make the stabilization PR? If not, I don't mind doing it tomorrow. (in either case, using my commit 877e9f5 as a base is likely a good idea to avoid a smidge of rebasing once #107429 is in)

[WaffleLapkin]

I'll live the PR to you :)

[tgross35]

Alright, I've opened #107624