mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-01 06:51:58 +00:00
Rollup merge of #97655 - steffahn:better-pin-box-construction-docs, r=thomcc
Improve documentation for constructors of pinned `Box`es Adds a cross-references between `Box::pin` and `Box::into_pin` (and other related methods, i.e. the equivalent `From` implementation, and the unstable `pin_in` method), in particular now that `into_pin` [was stabilized](https://github.com/rust-lang/rust/pull/97397). The main goal is to further improve visibility of the fact that `Box<T> -> Pin<Box<T>>` conversion exits in the first place, and that `Box::pin(x)` is – essentially – just a convenience function for `Box::into_pin(Box::new(x))` The motivating context why I think this is important is even experienced Rust users overlooking the existence this kind of conversion, [e.g. in this thread on IRLO](https://internals.rust-lang.org/t/pre-rfc-function-variants/16732/7?u=steffahn); and also the fact that that discussion brought up that there would be a bunch of Box-construction methods "missing" such as e.g. methods with fallible allocation a la "`Box::try_pin`", and similar; while those are in fact *not* necessary, because you can use `Box::into_pin(Box::try_new(x)?)` instead. I have *not* included explicit mention of methods (e.g. `try_new`) in the docs of stable methods (e.g. `into_pin`). (Referring to unstable API in stable API docs would be bad style IMO.) Stable examples I have in mind with the statement "constructing a (pinned) Box in a different way than with `Box::new`" are things like cloning a `Box`, or `Box::from_raw`. If/when `try_new` would get stabilized, it would become a very good concrete example use-case of `Box::into_pin` IMO.
This commit is contained in:
commit
5b64aab2b6
@ -284,8 +284,13 @@ impl<T> Box<T> {
|
||||
Self::new_zeroed_in(Global)
|
||||
}
|
||||
|
||||
/// Constructs a new `Pin<Box<T>>`. If `T` does not implement `Unpin`, then
|
||||
/// Constructs a new `Pin<Box<T>>`. If `T` does not implement [`Unpin`], then
|
||||
/// `x` will be pinned in memory and unable to be moved.
|
||||
///
|
||||
/// Constructing and pinning of the `Box` can also be done in two steps: `Box::pin(x)`
|
||||
/// does the same as <code>[Box::into_pin]\([Box::new]\(x))</code>. Consider using
|
||||
/// [`into_pin`](Box::into_pin) if you already have a `Box<T>`, or if you want to
|
||||
/// construct a (pinned) `Box` in a different way than with [`Box::new`].
|
||||
#[cfg(not(no_global_oom_handling))]
|
||||
#[stable(feature = "pin", since = "1.33.0")]
|
||||
#[must_use]
|
||||
@ -573,8 +578,13 @@ impl<T, A: Allocator> Box<T, A> {
|
||||
unsafe { Ok(Box::from_raw_in(ptr.as_ptr(), alloc)) }
|
||||
}
|
||||
|
||||
/// Constructs a new `Pin<Box<T, A>>`. If `T` does not implement `Unpin`, then
|
||||
/// Constructs a new `Pin<Box<T, A>>`. If `T` does not implement [`Unpin`], then
|
||||
/// `x` will be pinned in memory and unable to be moved.
|
||||
///
|
||||
/// Constructing and pinning of the `Box` can also be done in two steps: `Box::pin_in(x, alloc)`
|
||||
/// does the same as <code>[Box::into_pin]\([Box::new_in]\(x, alloc))</code>. Consider using
|
||||
/// [`into_pin`](Box::into_pin) if you already have a `Box<T, A>`, or if you want to
|
||||
/// construct a (pinned) `Box` in a different way than with [`Box::new_in`].
|
||||
#[cfg(not(no_global_oom_handling))]
|
||||
#[unstable(feature = "allocator_api", issue = "32838")]
|
||||
#[rustc_const_unstable(feature = "const_box", issue = "92521")]
|
||||
@ -1190,12 +1200,18 @@ impl<T: ?Sized, A: Allocator> Box<T, A> {
|
||||
unsafe { &mut *mem::ManuallyDrop::new(b).0.as_ptr() }
|
||||
}
|
||||
|
||||
/// Converts a `Box<T>` into a `Pin<Box<T>>`
|
||||
/// Converts a `Box<T>` into a `Pin<Box<T>>`. If `T` does not implement [`Unpin`], then
|
||||
/// `*boxed` will be pinned in memory and unable to be moved.
|
||||
///
|
||||
/// This conversion does not allocate on the heap and happens in place.
|
||||
///
|
||||
/// This is also available via [`From`].
|
||||
///
|
||||
/// Constructing and pinning a `Box` with <code>Box::into_pin([Box::new]\(x))</code>
|
||||
/// can also be written more concisely using <code>[Box::pin]\(x)</code>.
|
||||
/// This `into_pin` method is useful if you already have a `Box<T>`, or you are
|
||||
/// constructing a (pinned) `Box` in a different way than with [`Box::new`].
|
||||
///
|
||||
/// # Notes
|
||||
///
|
||||
/// It's not recommended that crates add an impl like `From<Box<T>> for Pin<T>`,
|
||||
@ -1458,9 +1474,17 @@ impl<T: ?Sized, A: Allocator> const From<Box<T, A>> for Pin<Box<T, A>>
|
||||
where
|
||||
A: 'static,
|
||||
{
|
||||
/// Converts a `Box<T>` into a `Pin<Box<T>>`
|
||||
/// Converts a `Box<T>` into a `Pin<Box<T>>`. If `T` does not implement [`Unpin`], then
|
||||
/// `*boxed` will be pinned in memory and unable to be moved.
|
||||
///
|
||||
/// This conversion does not allocate on the heap and happens in place.
|
||||
///
|
||||
/// This is also available via [`Box::into_pin`].
|
||||
///
|
||||
/// Constructing and pinning a `Box` with <code><Pin<Box\<T>>>::from([Box::new]\(x))</code>
|
||||
/// can also be written more concisely using <code>[Box::pin]\(x)</code>.
|
||||
/// This `From` implementation is useful if you already have a `Box<T>`, or you are
|
||||
/// constructing a (pinned) `Box` in a different way than with [`Box::new`].
|
||||
fn from(boxed: Box<T, A>) -> Self {
|
||||
Box::into_pin(boxed)
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user