Implement From<Box<T>>
for NonNull<T>
.
#80611
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This provides an implementation of
From<Box<T>>
forNonNull<T>
.It's a pretty small conceptual addition, but is good because but avoids a case where the operation is obviously sound, but you'd otherwise need unsafe to do it directly (at least, without an unwrap).
It also can be a bit subtle to implement this correctly (for example, my understanding is that using
NonNull::from
on a reference derived from the Box would have the wrong provenance), so it's good to provide a guaranteed-correct implementation.The biggest downside is that this operation leaks (err, it transfers responsibility for cleanup to the caller), but that seems like the point of this operation. This has been noted in the documentation, however, and is in a must_use message.
I didn't do this for the other smart pointer types (
Rc<T>
andArc<T>
) since it seemed less useful, and is semantically a bit hairier, I think. I'm happy to change that though, if desirable.I didn't make this generic over the Allocator parameter, mostly because the other From impls largely aren't (only a couple are). It's also not clear to me how that interacts with stability, although it's probably fine. Anyway, happy to change that as well.Actually I was wrong, most of the similar impls are generic over the allocator, so this is too.This is a trait implementation, so IIUC it's automatically stable (and thus needs to go through an FCP, I believe), and thus is marked as stable. I'm happy to change it to unstable if this wasn't correct information.