Tracking Issue for str_from_raw_parts

Feature gate: #![feature(str_from_raw_parts)]

This is a tracking issue for ACP#167, which adds core::str::from_raw_parts[_mut].

Public API

// core::str

pub const unsafe fn from_raw_parts<'a>(ptr: *const u8, len: usize) -> &'a str

pub const unsafe fn from_raw_parts_mut<'a>(ptr: *mut u8, len: usize) -> &'a mut str

Steps / History

Implementation (take 1): Implement str::from_raw_parts() and str::from_raw_parts_mut() #107207
Implementation (take 2): Initial implementation of str::from_raw_parts[_mut] #119466
Final comment period (FCP)¹
Stabilization PR

Unresolved Questions

None yet.

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

Rollup merge of rust-lang#119466 - Sky9x:str_from_raw_parts, r=dtolnay

Unrolled build for rust-lang#119466

Rollup merge of rust-lang#124100 - dev-ardi:master, r=workingjubilee

Unrolled build for rust-lang#124100

I'm not a fan of this. This saves a negligible amount of code but bunches up a whole lot of safety considerations. slice::from_raw_parts has language-level memory safety invariants, and str::from_utf8_unchecked has a single library-level safety invariant (that the slice contains valid UTF-8). In code, these should be justified separately. The example in rust-lang/libs-team#167 was

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

but it should have really been

// SAFETY: <explain why ptr and len make a valid slice>
let bytes = unsafe { slice::from_raw_parts(ptr, len) };
// SAFETY: <explain why this slice is UTF-8>
unsafe { str::from_utf8_unchecked(bytes) }

I don't see the value of combining these to

// SAFETY: <explain why ptr and len make a valid slice and why this slice is UTF-8>
unsafe { str::from_raw_parts(ptr, len) }

The proposed documentation also says

The pointed-to bytes must be valid UTF-8. If this might not be the case, use str::from_utf8(slice::from_raw_parts(ptr, len)), which will return an Err if the data isn’t valid UTF-8.

which kind of admits that there are two safety considerations that should be handled by two function calls. In the end, docs could just recommend str::from_utf8_unchecked(slice::from_raw_parts(ptr, len)).

This API intends to be the borrowed equivalent the already-stable String::from_raw_parts, and fill in the two missing methods in the table below, bringing the string API more in line with the slice API.

	String	Slice
`&`	❌ `str::from_raw_parts`	✅ `slice::from_raw_parts`
`&mut`	❌ `str::from_raw_parts_mut`	✅ `slice::from_raw_parts_mut`
Owned	✅ `String::from_raw_parts`	✅ `Vec::from_raw_parts`

The documentation could be improved to properly express the safety concerns.

Also note that the ACP was accepted because of the existence of String::from_raw_parts, which by the same argument could be written as String::from_utf8_unchecked(Vec::from_raw_parts(ptr, len, cap)).

If you really don't want these functions to appear in your codebase, consider the clippy::disallowed_methods lint:

# clippy.toml
disallowed-methods = [
    "core::str::from_raw_parts",
    "core::str::from_raw_parts_mut",
    "alloc::string::String::from_raw_parts",
    # ...
]

It looks like String::from_raw_parts's safety documentation was at some point copy-pasted from Vec::from_raw_parts's, but it has since diverged and is currently much less detailed. It for example misses the invariant "The allocated size in bytes must be no larger than isize::MAX". This is exactly the issue I'm trying to point out, the documentation basically has to say

Safety

Everything in Vec::<u8>::from_raw_parts's safety requirements

Everything in String::from_utf8_unchecked's safety requirements

at which point why not just make those two calls?

String::from_raw_parts is one method with this issue, does this justify adding two more?

I'll copy my comment from the ACP here, as something potentially still worth discussing at stabilization time:

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.

(This is the same sentiment as #119206 (comment) above.)

Hi, is there any progress on this feature? Seems there's no outstanding questions.

There is an open discussion on whether this should be done.

If consistency is the driving argument, we should look at this complete table:

	String	Slice
&	❌ `str::from_raw_parts`	✅ `slice::from_raw_parts`
&mut	❌ `str::from_raw_parts_mut` ❌ `str::into_raw_parts`	✅ `slice::from_raw_parts_mut` ❌ `slice::into_raw_parts`
Owned	✅ `String::from_raw_parts` ❌ `String::into_raw_parts`	✅ `Vec::from_raw_parts` ❌ `Vec::into_raw_parts`

Rollup merge of rust-lang#136775 - robertbastian:patch-2, r=Amanieu

Unrolled build for rust-lang#136775

Rollup merge of #136775 - robertbastian:patch-2, r=Amanieu

Rollup merge of rust-lang#136775 - robertbastian:patch-2, r=Amanieu

I think this should be moved to str::from_raw_parts, possibly keeping std::str::from_raw_parts and core::str::from_raw_parts as aliases, for consistency with str::from_utf8 (#131114).

Navigation Menu

Repository navigation

Tracking Issue for `str_from_raw_parts` #119206

Public API

Steps / History

Unresolved Questions

Safety

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for str_from_raw_parts #119206

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

robertbastian commented on Jun 18, 2024

Sky9x commented on Jun 19, 2024

robertbastian commented on Jun 20, 2024

Safety

scottmcm commented on Oct 1, 2024

PureWhiteWu commented on Dec 9, 2024

robertbastian commented on Feb 9, 2025

abgros commented on Jul 8, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for `str_from_raw_parts` #119206