Tracking Issue for CStr::is_empty

[jmillikin]

Feature gate: #![feature(cstr_is_empty)]

This is a tracking issue for adding an is_empty() method to core::ffi::CStr.

ACP: rust-lang/libs-team#106

Public API

// core::ffi

impl CStr {
	pub const fn is_empty(&self) -> bool;
}

Steps / History

• Implementation: Add is_empty() method to core::ffi::CStr. #102445
• Final comment period (FCP)¹
• Stabilization PR: Stabilize feature cstr_is_empty #111043

Unresolved Questions

• None yet.

Footnotes

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

[jmillikin]

Gentle ping for @rust-lang/libs-api -- would it be possible to start the FCP now? I don't think there's much API surface to review.

[jmillikin]

(pinging someone from the libs team, per instructions at https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html)

@cuviper I'd like to start the FCP for this feature. The new method has been in nightly since v1.66, and it'd be nice to have it in stable.

[jmillikin]

Timed out waiting for someone to start the FCP -- since there's not much to discuss regarding the API, I sent in PR #111043 to stabilize.

[BurntSushi]

@rfcbot fcp merge

[rfcbot]

Team member @BurntSushi 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.

[BurntSushi]

@rust-lang/libs-api This issue is for stabilizing CStr::is_empty, which seems sensible. It returns true in precisely the cases where CStr::to_bytes().is_empty() returns true. One odd thing here is that there is no CStr::len method, but that can always be added in the future.

[jmillikin]

Thank you for starting the FCP!

One odd thing here is that there is no CStr::len method, but that can always be added in the future.

My understanding from the CStr docs is that a future version is expected to remove the construction-time length check, so new() would become cheap and len() (if it existed) would be expensive (basically C's strlen()).

Having a len() that iterates through the entire value seems surprising enough that it's worth its own ACP, and I don't feel I have enough context to be the person to write it.

[BurntSushi]

@jmillikin Yes that makes sense. I just mean that it is somewhat odd from an API perspective. Usually if there's an is_empty and its a collection, then there's also a len method. And vice versa. I raise it as something that I find a little odd, but not a blocker for moving forward.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[madsmtm]

Having a len() that iterates through the entire value seems surprising enough that it's worth its own ACP

But is this not also the case for is_empty? In the future, is_empty would iterate through the entire value, which I think is just as surprising.

[zopsicle]

is_empty just checks the first byte. No iteration necessary. That's why it's worth having in addition to len, as len == 0 would be linear time.

[madsmtm]

is_empty just checks the first byte. No iteration necessary. That's why it's worth having in addition to len, as len == 0 would be linear time.

Right, didn't actually think that through.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.