io: misc improvements

[carllerche]

Tracking misc smaller improvements to tokio-io.

This issue is to be closed once there are no remaining breaking changes to make or remaining breaking changes are tracked in separate issues.

Features

• AsyncRead::chain, take, and any other missing helpers.
• split helper. (io: bring back split utility #1521)
• add AsyncBufRead implementations.

Polish

• module layout

[taiki-e]

#1301 just added traits and combinators. We should add AsyncBufRead implementations to some types. (added check box)

EDIT: It seems that there were fewer types that could implement this than I had thought.
EDIT2: It seems this is done.

[jimmycuadra]

Can someone clarify which types are intended to implement AsyncBufRead? I was just trying to figure out how to loop over the lines of stdin and discovered tokio::io::Stdin doesn't implement this trait, which led me to this issue. Sounds like this is intended but just hasn't been done yet?

[carllerche]

@jimmycuadra any type that can implement it should.

[jebrosen]

This looks like a good place to bring this up: in tokio 0.1, AsyncRead was implemented for some types in std::io such as Repeat, Chain, and Take with corresponding combinators (sometimes only usable when the underlying type itself implemented Read?). async_std and futures_util have corresponding implementations for most or all of the utilities in std.

So, what makes the most sense for tokio 0.2? I had a few ideas:

• Implement AsyncRead for the existing std types where possible. Where not possible, they would be have to be implemented in a different way. tokio 0.1 did this for some types.
• Implement a Read-to-AsyncRead adapter. futures-util calls this AllowStdIo. If this option is chosen, perhaps we could use some kind of marker supertrait like SafeAsAsyncRead as a speed bump against using it with arbitrary Read types that might block.
• Reimplement parallel types for all of std (this is what async_std does).
• Reexport or wrap types from another crate such as futures-util.
  • I think this is currently the most direct option for users of tokio-io as of 0.2.0-alpha.6, via futures_tokio_compat.

---

On another note, I would love to see an AsyncSeek trait in tokio and implemented for (at least) Cursor and File for feature parity with std.

[hawkw]

• Implement AsyncRead for the existing std types where possible. Where not possible, they would be have to be implemented in a different way. tokio 0.1 did this for some types.

@jebrosen I'm not convinced it's good idea to implement AsyncRead/AsyncWrite for types that also implement Read/Write. There are several methods in Async{Read, Write}Ext whose names and argument types overlap with Read or Write methods, so it's possible that users might find themselves in situations where they have to explicitly state which trait is being used. It would be a shame to have to write stuff like

AsyncWriteExt::write_all(&mut my_writer, buf)

instead of

my_writer.write_all(buf)

[jebrosen]

In writing my previous comment I had actually missed a huge amount of functionality that was already implemented, and #1632 adds the few utilitites I was especially interested in.

I believe these are all that's missing now compared to std:

• LineWriter
• Seek trait - io: add AsyncSeek trait #1641
• AsyncBufReadExt::split() (lines() but with any delimiter) - io: add AsyncBufReadExt::split #1642
• AsyncReadExt::bytes()

[hawkw]

#1642 adds AsyncBufRead::split.