Roadmap for after Rust 1.64?

[chrysn]

core::ffi::CStr and alloc::ffi::CString have been stabilized for Rust 1.64, which is due to become stable in 9 weeks from now.

Once that has landed, what remains for this crate to do?

• It provides some operations in a nightly-const fashion. (Some of that wouldn't even need nightly any more, eg. from_bytes_with_nul_unchecked; still, the corresponding core function does not spring to life as const).
• It still provides dedicated types for libraries that have public cstr somewhere -- these can't just change their types to the new core ones without breaking API.

Do you intend to keep maintaining the crate as a staging ground for constification of the core library, or other experimentation? Is there any user base that can not go to 1.64 speedily, or that can not do the API change toward core library? (A quick survey of the most popular dependents of cstr_core shows they're all in pre-1.0 stage, and I didn't check which of them use CStr types publicly) Or will this library just be deprecated and development ceased?

If it is kept maintained as a staging ground, it may make sense to provide From and Into for the core types (they should be trivial as they can be unchecked); then APIs can pivot to core's interfaces, and whoever needs const methods can still into them and use cstr_core privately.

---

From the perspective of using it from riot-wrappers, I'm still checking whether there is any constness that I'm missing from the core library, push for constification if needed (pointing to this project to illustrate it works), and plan to make the API break as soon as 1.64 is available.

[chrysn]

I completely missed that the cstr! macro is not part of std/core. Thus, if you should decide decide to mothball this crates CStr type, there are two ways forward:

• A newer version of this crate provides all it provides now, but based on the core CStr type
• The cstr crate becomes no_std (which it only can depending on 1.64), and only a single cstr! macro is used for both std and no_std settings.

[Amanieu]

The point of this crate was to make the CStr and CString types available to no_std code. Now that these types are in core, it is no longer needed and I plan to deprecate this crate.

The cstr! macro should be upstreamed into the standard library.

[upsuper]

To be honest, I feel now that CStr is in core, maybe Rust should just add a new prefix form c"xxx" for static CStr.

[chrysn]

Fine with me, thanks for clarifying.

c"xxx"

I think it's a bit too niche to warrant a dedicated literal type, but I hope the standard library will provide the cstr! macro eventually.

[rilipco]

Are there any plans to publish a new version (patch or minor) that just reexports the core types akin to the semver-trick? This would be quite beneficial when dealing with a dependency that uses this crate but should also inter-op with the new core types (particularly &CStr).

I guess the alternative would be to port those crates from cstr_core to core, which however would be a breaking change.

[Amanieu]

I'm happy to accept a PR for that. Now that c"" is stable and CStr is in core, there is no longer any reason to maintain this crate.