io: remove Async{Read,Write}Ext

[carllerche]

All the util functions should be moved to AsyncRead and AsyncWrite.

The same should be applied to all other traits defined by Tokio:

• AsyncSeek
• AsyncBufRead

[jonhoo]

What is the rationale for this change?

[carllerche]

@jonhoo The original intent of splitting AsyncRead and AsyncReadExt was that they could be in different crates w/ different levels of stability.

As we reach 1.0, both the helpers and the core trait have the same level of stability.

[aknuds1]

I'd like to work on this one if I may.

[carllerche]

@aknuds1 that should be fine. I would coordinate w/ the stream PR as this might cause some merge conflicts (see which files it modifies): #3277

The idea is to move all the helper fns from the ext traits onto the core traits.

[carllerche]

It's looking like we are going to be unable to move forward on this and will be required to leave the Ext traits as is.

First, moving the fns from *Ext back onto the core trait will prevent using the util methods with trait objects. Second, naming the trait *Ext is a convention listed here: https://github.com/rust-lang/rfcs/blob/master/text/0445-extension-trait-conventions.md

Context:

• Remove io::util::Async{Read,Write}Ext #3291 (comment)
• Remove io::util::Async{Read,Write}Ext #3291 (comment)

[aknuds1]

@carllerche Ow, that's too bad :/ Want me to close the PR?

[Darksonn]

I thought we could be saved by implementing AsyncRead for &mut dyn AsyncRead, but we already do that, and calling the methods through that impl is rather inconvenient as I also mentioned on the PR.

For example, this compiles:

async fn send_recv_all(
    mut read: &mut (dyn AsyncRead + Unpin),
    mut write: &mut (dyn AsyncWrite + Unpin),
    input: &[u8],
) -> std::io::Result<Vec<u8>> {
    (&mut write).write_all(input).await?;
    (&mut write).shutdown().await?;

    let mut output = Vec::new();
    (&mut read).read_to_end(&mut output).await?;
    Ok(output)
}

@aknuds1 I assume the Americans have gone to bed now, but yeah we will probably have to close the PR because of this.

[aknuds1]

@Darksonn Yeah making the same assumption :)

[carllerche]

Ok, given the issues hit and the established convention, we are going to leave this as is.

@aknuds1 thanks for your work! Even if it didn’t land it was really helpful to get us to the conclusion.