chrefr
March 24, 2022, 1:05am
1
* Unpin because of trait objects, for which the structural auto
* trait functionality does not apply (e.g., Box<dyn Foo> would
* otherwise not be Unpin).
*
* Another type with the same semantics as Box but only a conditional
* implementation of `Unpin` (where `T: Unpin`) would be valid/safe, and
* could have a method to project a Pin<T> from it.
*/
#[stable(feature = "pin", since = "1.33.0")]
#[rustc_const_unstable(feature = "const_box", issue = "92521")]
impl<T: ?Sized, A: Allocator> const Unpin for Box<T, A> where A: 'static {}
#[unstable(feature = "generator_trait", issue = "43122")]
impl<G: ?Sized + Generator<R> + Unpin, R, A: Allocator> Generator<R> for Box<G, A>
where
A: 'static,
{
type Yield = G::Yield;
type Return = G::Return;
fn resume(mut self: Pin<&mut Self>, arg: R) -> GeneratorState<Self::Yield, Self::Return> {
Shouldn't it include the bound A: Unpin too? Box contains a field of type A, and if it's !Unpin, we can still unpin it using e.g. Box::into_raw_with_allocator().
CAD97
March 24, 2022, 4:30am
2
It depends on whether Box semantically pin projects its fields. If Pin<&mut Box<T>> doesn't let you get Pin<P<A>>, the the allocator is never actually pinned.
1 Like
system
June 22, 2022, 4:30am
3
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.