Only include the await! macro when compiling with nightly Rust

[eldruin]

In preparation to removing the unstable feature, I think it would be interesting not to include the await! macro on non-nightly builds, since it cannot work.
docs.rs uses nightly Rust for the generation so the macro will be there.

Disadvantadges:

• It may be confusing not to have the macro when attempting to use it on non-nightly Rust although it is there in the docs.

Thoughts?

[therealprof]

I guess this begs the larger question of whether it makes sense at all to continue supporting those unstable features or whether we should completely remove them. I don't think nb will play a major role in our async story.

[eldruin]

Yes, probably. Specially since changes to generators in Rust nightly would break it without us being able to do anything about it and furthermore, await is a reserved keyword in Rust edition 2018.
We quickly agreed to just remove the unstable feature in the last EWG meeting but maybe this was not thought thoroughly.

Are there actual users of nb's try_nb! or await!?
try_nb! is not problematic, but a lot has happened since futures 0.1.

If removing these this crate will get really thin. Just nb::Result and block!. Many of the examples about the async story would also need to go.

[therealprof]

We quickly agreed to just remove the unstable feature in the last EWG meeting but maybe this was not thought thoroughly.

I don't recall agreeing only for the unstable flag to go or the functions themselves. ;)

Are there actual users of nb's try_nb! or await!?
try_nb! is not problematic, but a lot has happened since futures 0.1.

Don't know but since unstable things are not only clearly marked unstable but also only working with a nightly compiler I'm not worried at all. But we can certainly discuss later today in the meeting.

If removing these this crate will get really thin. Just nb::Result and block!. Many of the examples about the async story would also need to go.

Well, that's its main use.

[therealprof]

As discussed in the 2020-06-30 meeting we'll wait a few more days and if there're no major objections we're going to remove all unstable cfg-gated functionality and move everything to edition 2018. If needed we can readd the removed functionality in a future proof way without breakage after the 1.0 release.