AsyncRead, AsyncWrite traits

[tmandry]

We need an async form of the Read and Write traits.

There are multiple versions of this in the ecosystem:

futures: AsyncRead, AsyncWrite
tokio: AsyncRead, AsyncWrite
async_std: Read, Write

Relevant design decisions:

• How to handle ReadBuf (Tracking Issue for RFC 2930 (read-buf) rust#78485), should we include a method without it like Read has
• Whether to include vectored I/O

[ids1024]

async_std

These re-export the versions in futures.

These traits are a fair bit harder to implement than the normal std versions of Read/Write, since it's necessary to implement fn poll_read() rather than something like async fn read(). It seems unsatisfactory to me to stabilize something like that without making it easier to implement.

[Darksonn]

@ids1024 In principle that same complaint could be targeted at the Stream trait, which is quite a bit further towards stabilization.

[djc]

• How to handle ReadBuf (Tracking Issue for RFC 2930 (read-buf) rust#78485), should we include a method without it like Read has

Seems to me that Read wouldn't have the non-buf version if we'd had the ReadBuf abstraction at the time it was stabilized. In other words, I definitely think it would be preferable to require the buf kind for new traits.

These traits are a fair bit harder to implement than the normal std versions of Read/Write, since it's necessary to implement fn poll_read() rather than something like async fn read(). It seems unsatisfactory to me to stabilize something like that without making it easier to implement.

While we still don't have GAT, pretty sure we wouldn't want to require boxing at this level of the stack.

Also, implementing these traits will be relatively rare IMO.

[taiki-e]

it shouldn't probably be difficult to integrate both io traits once rust-lang/rust#69941 and rust-lang/rust#78485 are stable.

AFAIK, they should be sufficient to meet the requirements that tokio requires for async io trait. And, futures tend not to actively add features that are not stable in the standard library.
(Aside from the question of whether to default poll_read or poll_read_buf.)

related: rust-lang/futures-rs#2209, rust-lang/futures-rs#1826, rust-lang/futures-rs#1761

[lqf96]

We may also want to standardize the AsyncSeek trait since it's present in futures, tokio and async_std...

[antoinevg]

It would also be great if this didn't require no_std library authors to come up with their own (incompatible) version.

There was a conversation in futures-rs that ended up dead-locking around the use of the iovec crate rather than a generic &[&[u8]] parameter:

rust-lang/futures-rs#1455

While I am sympathetic to the view that standard io libraries tend to be highly dependent on an operating system in order to avoid implementation hell maybe we can give some thought to the idea that io abstractions such as Read or Write are universal enough that some place could be found for them in some kind of core::io or async_core::io namespace?

[taiki-e]

@antoinevg As for no_std, I don't think the situation has changed since the previous decision in rust-lang/futures-rs#860.

[tmandry]

There is progress being made on moving the Error trait into core: rust-lang/project-error-handling#3

[tmandry]

Closing in favor of nrc/portable-interoperable#5.