Why aren't AsyncRead and AsyncWrite symmetrical with their synchronous counterparts?

[alshdavid]

Just a general question about AsyncRead and AsyncWrite.

Given the usage, I'd imagine the trait would look something like

pub trait AsyncRead {
  fn read<'a>(&'a mut self, buf: &'a mut [u8]) -> impl Unpin + Future<Output = io::Result<usize>>;
}

Which resembles std::io::Read and is easy to work with and implement. However, the real traits have a poll_read method, which is difficult to implement.

For example, when trying to forward calls to read to a wrapper type

pub enum File {
    Physical(tokio::fs::File),
    InMemory(crate::fs::memory::File),
}

impl AsyncRead for File {
    fn poll_read(
        self: Pin<&mut Self>,
        cx: &mut std::task::Context<'_>,
        buf: &mut tokio::io::ReadBuf<'_>,
    ) -> std::task::Poll<io::Result<()>> {
        match self {
            File::Physical(file) => {
                // What do I do here?
            },
            InMemory(_) => {
               // What do I do here as well?
           }
        }
    }
}

Why are the AsyncRead and AsyncWrite traits the way they are?

[ADD-SP]

Why are the AsyncRead and AsyncWrite traits the way they are?

I'd like answering this question by asking several questions.

Let's say we are using native operating system features to implement a async runtime.

pub trait AsyncRead {
  fn read<'a>(&'a mut self, buf: &'a mut [u8]) -> impl Unpin + Future<Output = io::Result<usize>>;
}

How to use this signature to implement an async socket?

[Darksonn]

The main advantage of the current traits is that it's possible to read and write at the same time with the current design. It would have been impossible to implement tokio::io::split with the design you propose because the read future holds a mutable borrow of the IO resource, preventing you from calling write for the entire duration of the read.