Tracking Issue for `cstr_count_bytes`

[tgross35]

Feature gate: #![feature(cstr_count_bytes)]

This is a tracking issue for adding a .count_bytes() method to CStr.

Public API

impl CStr {
    pub fn count_bytes(&self) -> usize;
}

Steps / History

• ACP: Add a CStr::count_bytes() method libs-team#256
• Implementation: Implement cstr_count_bytes #114443
• Final comment period (FCP)¹ Tracking Issue for cstr_count_bytes #114441 (comment)
• Stabilization PR Stabilize cstr_count_bytes #123661

Unresolved Questions

• None yet.

Footnotes

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

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

I propose stabilizing this signature, including the constness:

impl CStr {
    pub const fn count_bytes(&self) -> usize;
}

Here is the comment where our team made the suggestion to expose this under the name .count_bytes(): rust-lang/libs-team#256 (comment)

New developments since then: the CStr::bytes iterator was added just last week in #104353. With that, an alternative spelling to evaluate would be .bytes().count() using the Iterator trait's count (possibly with a non-default implementation specific to this impl for performance). But this couldn't be const until perhaps the distant future, and wouldn't be straightforwardly locatable in the method list of CStr or in autocomplete..

This method comes with a doc alias that makes it show up in rustdoc search for strlen.

The constness of this signature has so far been tracked separately under #113219, and involves a T-lang matter. I have proposed an FCP in that issue in parallel to this one that would relinquish the constness of count_bytes into a T-libs-api decision only. If both FCPs go through, we stabilize const fn count_bytes. If only the FCP here goes through and not the one in #113219, then we stabilize fn count_bytes and the constness will be left unstable for now.

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.