Should the Future trait be part of the prelude

Personally find lack of Error most annoying not to be included. Others suggested Debug/Display/HashMap just don't give the feeling. (Like already mentioned, write! macro also gives annoyance due to Write not included.) Just not been writing enough so far to have feeling either way about Future.

My response to that is that those other traits don't have language-level features built on top. Future has async built on top, which makes it appropriate for it to be in the prelude IMO.

The counter-argument I can think of is that Future isn't imported directly with a use statement all that often I think.

Currently I don't think Future would be all that useful in prelude. Users would do use futures::prelude::* anyway in practice. As std::future::Future doesn't have pretty much anything, its only method, poll, isn't really useful for most code. It could be useful in functions returning impl Future, but this won't be really necessary with async fn as well.

1 Like