Stabilize standard-library futures support

[shepmaster]

Do we want to keep a separate feature flag (e.g. std-futures) or should we assume that everyone with Rust 1.36 wants this?

Since we also pull in futures-preview and pin-project, it seems like a separate flag is appropriate for now.

Is there a non -preview that we should depend on? If not, should we wait for it?

[jplatte]

Personally, I'd like to see a new release using syn and quote 1.0 sooner rather than later, simply for improved initial build times in projects that only depend on the old versions through snafu. To me it looks like futures-rs is under-staffed¹ and probably won't see a final 0.3 release any time soon, so waiting would delay snafu's release by a lot.

¹: many issues sit there without any comments for a long time, and there haven't been many commits recently

[shepmaster]

Thanks for your feedback!

Personally, I'd like to see a new release using syn and quote 1.0 sooner rather than later, simply for improved initial build times in projects that only depend on the old versions through snafu.

That's been merged, but I'd like to try and get some other breaking changes in for 0.6 as well, to minimize the number of disruptive upgrades.

The big reason I'd consider this for 0.6 is because async / await will be stable... tomorrow, I guess. Hmm.

I wonder if there's a way to split up our functionality into "pure" standard library and futures-preview bits...