`str::from_raw_parts`

[Kixiron]

Proposal

Add the str::from_raw_parts and str::from_raw_parts_mut apis

mod str {
    pub const unsafe fn from_raw_parts<'a>(data: *const u8, len: usize) -> &'a str { ... }
    
    pub unsafe fn from_raw_parts_mut<'a>(data: *mut u8, len: usize) -> &'a mut str { ... }
}

Problem statement

Creating a str from raw parts is a fairly boilerplate filled task.

Motivation, use-cases

Often in unsafe or FFI-related code users end up creating strings from their constituent parts, pointers and lengths. However, as of now there's no direct way to do this for str, instead the user must first create a byte slice and then create a string slice from said byte slice, requiring the user to write more code than they really should have to. This proposal turns the pattern of

let bytes = slice::from_raw_parts(ptr, len);
str::from_utf8_unchecked(bytes)

into a simple str::from_raw_parts(ptr, len) call.

Solution sketches

Instead of putting the functions within the str module, they could be methods on str itself to keep the user from having to import the str module or fully qualifying core::str::from_raw_parts wherever they need to use the function.

Links and related work

• Implementation PR

[the8472]

How well can one trust FFI code though? There may be subtle impedance mismatches such as the C side being fine with overlong sequences, unpaired surrogates and such.
Imo code at a safety boundary should validate utf8 by default and only use _unchecked after carefully considering the API guarantees and observing a performance benefit.

So idk if making the unchecked route less verbose than the checked route is a good idea.

[scottmcm]

I'm not convinced that one more function call is "a fairly boilerplate filled task". That's especially true for unsafe code where the hard part is demonstrating that the safety conditions have been met.

Because of that, I think two calls is actually better when the two safety conditions are very different, like they are here.

[joshtriplett]

We discussed this in today's libs-api meeting. We went back and forth a bit (and mused about whether it should have utf8 in the name), before noting that String::from_raw_parts already exists. Given String::from_raw_parts, we should add these. ACP accepted.