Closed theemathas closed 1 month ago
We discussed this in today's @rust-lang/libs-api meeting. We'd like to add most of these, with some tweaks:
_non_null_parts
methods to just be _parts
(e.g. from_parts
/into_parts
).Vec::as_non_null
for now. We'd appreciate advice and recommendations from @rust-lang/opsem on what the API should look like to avoid UB.
Vec::as_non_null
takes &self
, that would be safe because it's taking a reference to Vec which contains a pointer, so it isn't UB to write through the returned NonNull. But we still want to defer those because we'll want to name them consistently with the slice methods.We're accepting that subset of the ACP, and we'd ask you to open a new ACP for the remaining methods with guidance from T-opsem.
Proposal
Problem statement
NonNull
is the correct type for implementing unsafe data structures. However, using them requires extra conversions fromBox
andVec
, meaning that the path of least resistance is using*mut
/*const
raw pointers. Thus, with similar motivation to the ACP forNonNull
convenience methods, I'm proposing some convenience methods onBox
andVec
.Motivating examples or use cases
The linked list book has an example of how someone might want to allocate some memory with
Box
, convert it intoNonNull
for storage, and later convert it back toBox
for deallocation.Solution sketch
I would like to proposing the following API additions:
Alternatives
The status quo: users need to do an extra layer of conversion to/from
NonNull
.Vec::as_non_null
might take&self
instead of&mut self
.We might also want convenience methods for slices.
Links and related work
There are already some methods on
NonNull<[T]>
.What happens now?
This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
Second, if there's a concrete solution: