FYI: We had a writing session on this today, and we should be having the first (of hopefully 2-3) status-quo stories coming for this soon.

ooh, nice!

An interesting aspect to this story could be: does Alan write an impl for tokio's AsyncWrite or future's AsyncWrite ?

I'm not sure if "wrap" in the description is the same as this, but I keep wanting it to be easier to delegate AsyncRead and/or AsyncWrite to an inner type, either through a pin projection or by unpinning. The vast majority of AsyncRead/Write implementations I write are just boilerplate delegation. It would be cool if that could look like a derive macro, but that would also have to be aware of pin projection

An example in case it's not clear:

#[derive(AsyncRead, AsyncWrite)]
struct SomeType {
    #[async_read]
    #[async_write]
    unpinnable_inner: SomethingReadAndWrite
}

// would result in 👇 
impl AsyncRead for SomeType {
    fn poll_read(
        mut self: Pin<&mut Self>,
        cx: &mut Context<'_>,
        buf: &mut [u8],
    ) -> Poll<Result<usize>> {
        Pin::new(&mut self.unpinnable_inner).poll_read(cx, buf)
    }
}

impl AsyncWrite for SomeType {
    fn poll_write(
        mut self: Pin<&mut Self>,
        cx: &mut Context<'_>,
        buf: &[u8],
    ) -> Poll<Result<usize>> {
        Pin::new(&mut self.unpinnable_inner).poll_write(cx, buf)
    }

    fn poll_flush(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<()>> {
        Pin::new(&mut self.unpinnable_inner).poll_flush(cx)
    }

    fn poll_close(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<()>> {
        Pin::new(&mut self.unpinnable_inner).poll_close(cx)
    }
}

and the !Unpin equivalent is that but with self.project().non_unpin_inner.poll_whatever.

This might be identical to what the issue is about, I'm not sure

Yes, that is what this issue is about. The difficulty of writing wrappers that work with Poll, the need to use pin-project, etc.