Make a final decision for the prelude

Right now I feel we should go with the following prelude:

pub use crate::future::Future;

pub use crate::io::BufRead as _;
pub use crate::io::Read as _;
pub use crate::io::Seek as _;
pub use crate::io::Write as _;

pub use crate::stream::Stream;

pub use crate::time::Timeout as _;

I don't think we should add or remove anything from this list, but am unsure about which traits should be anonymously imported (as _) and which shouldn't. I feel like fully importing traits like Read could be a potential source of conflicts if the user uses std::io::Read in their code at the same time.

What about trait Stream? Should that one be anonymous or not? In a way, it is fundamental just like Iterator, which is even in the std prelude. So maybe we should import it fully.

But I'm still not 100% decided...

[skade]

Would that be async_std::prelude or async_std::io::prelude?

The former.

[skade]

I'm a bit split there, as Read in the stdlib is not in prelude, but on the other hand, all async_std does is io. Do we have a async_std::io::prelude module? (for easy porting)

Also, we should go the same route as std and export async_std::v1::prelude as async_std::prelude for future-proofing.

Do we have a async_std::io::prelude module? (for easy porting)

We don't. Perhaps we should import traits Read/Write/Seek/BufRead in the main prelude anonymously and import them fully in io::prelude?

Also, we should go the same route as std and export async_std::v1::prelude as async_std::prelude for future-proofing.

As far as I understand, Rust's prelude is versioned so that a compiler flag, Cargo.toml, or Rust edition can choose the appropriate prelude version, which is then automatically imported by the compiler. And users never have to even think about prelude versions.

But our prelude is not automatically imported and users always have do it by hand. If it was versioned, they would write:

use async_std::prelude::v1::*;

This doesn't look pretty and I find that more concerning than the possibility of making a mistake in our prelude.

[skade]

The versioning story of the prelude in libstd is currently that std::prelude is an alias for std::v1::prelude. In the case of an update, users can still import std::v1::prelude for easy upgrades and temporary compatibility.

Users would only use. std::io::prelude. Thinking about it further, we can migrate to this strategy though, transparently, should the need arise.

[skade]

We don't. Perhaps we should import traits Read/Write/Seek/BufRead in the main prelude anonymously and import them fully in io::prelude?

That sounds like a good idea!

The versioning story of the prelude in libstd is currently that std::prelude is an alias for std::v1::prelude

Hmm, I just tried this:

use std::prelude::Box; // doesn't compile
use std::prelude::v1::Box; // compiles

which means std::prelude is not really an alias for std::prelude::v1. Or?

[skade]

Oh, wait. Misread. I think what the compiler introduces is std::prelude::v1 on top of every program... Forget my rambling.

In any case, besides the point, I'm fine with async_std::prelude.

I think we can close this issue since it's been resolved even before the initial release.