Make from_bytes_with_nul nightly const

[chrysn]

Filing this as an issue for initial feedback before I turn the pile of test I have around into a proper PR.

Steps needed (conditional to the nightly feature unless it happens to work on MSRV too; in increasing order of contentiousness):

• trivially constify FromBytesWithNulError constructors
• trivially constify to_bytes_with_nul and to_str
• Use more nightly features: const_str_from_utf8, const_slice_from_raw_parts (see below)
• constify to_bytes: Going through from_raw_parts seems to be the easiest way to do my_slice[..my_slice.len() - 1] in a const function right now; this introduces unsafe which can be easily argued to be sound.
• constify from_bytes_with_nul: This needs as a const memchr, which I don't expect the memchr crate to provide. As I'm unaware of a mechanism to use different code branches for const and non-const evaluation, and memchr is probably used for actual performance reasons here: Would this warrant having a const_from_bytes_with_nul function (which'd use a more inefficient manual const implementation of memchr) until there is a choice that's ideal for both cases?

Is any of that a no-go for the nightly feature, and do you have preferences on whether to accept reduced run-time performance of an unoptimized memchr or rather have a separate function name for const from_bytes_with_nul?

---

Use case: In the riot-wrappers crate I'm getting a name as a const byte array from C through bindgen, and no matter how hard I push LTO & co, a non-const access function doesn't eiliminate the error cases. With everything in there const, the access function can be replaced with a const value, and that pushes the panics to the build time.

[Amanieu]

For from_bytes_with_nul you could try using https://doc.rust-lang.org/nightly/std/intrinsics/fn.const_eval_select.html, but this is unlikely to ever be stabilized.

For your specific use case you can use from_bytes_with_nul_unchecked which is already available as a const fn with the nightly feature.

[chrysn]

I'm trying to avoid unchecked because there's nothing on the C side that guarantees upholding the null properties require by CStr.

The const_eval_select is nice for other applications, but I'm looking at the road toward getting a const result right from cstr_core, and const_eval is probably not suitable for here -- my impression of the nightly feature is that it's only there as long as some const stuff can not be done in stable, but will compatibly become available on stable over time.

Do I take your comment right that you'd rather not have more nightly features added at this time?

[Amanieu]

const_eval_select is a mechanism for using different code paths for const and non-const evaluation. The idea is to use a const-compatible version of memchr for const-eval while using an optimized version at runtime.

I'm happy to add a new nightly feature. However since const_eval_select is unlikely to be stabilized anytime soon, this means that the const version of from_bytes_with_nul will only be available on nightly Rust.

If you need this to be available on stable Rust then a separate const_from_bytes_with_nul is probably the only reasonable option.

I'm trying to avoid unchecked because there's nothing on the C side that guarantees upholding the null properties require by CStr.

You could just check it yourself with your own const version of memchr.

[chrysn]

Doing an own check works for the time being, but then I'd still need const to_str -- but that works with fewer problems, PR incoming.

I'd leave this open for whenever it's the right time to do from_bytes_with_nul (but understand if you prefer to close it WONTFIX FORNOW due to the memchr hassle).

[Amanieu]

I'm happy to accept an implementation that uses const_eval_select for a const from_bytes_with_nul.

[chrysn]

I'll add that then, no hurry with a release until that's done. Thanks.