Revert #[warn(unstable)] by default

[SimonSapin]

One of the changes introduced by f3b67af is:

• On the nightly channel, use of unstable APIs generates a warning.

I think this should be reverted for now. Here is why:

A warning is only useful when it is actionable. “You should not do this” is ideally accompanied by “do that instead”. Maintainers fix their code and the warning goes away. But this is not the case of most unstable warnings, there is not yet a stable equivalent of the functionality. Therefore, in order to find the few actionable warnings or just not be drowned in the sheer amount of output, maintainers are lead to add #![allow(unstable)] to their crates. This is not great, because they (or at least I) are likely to forget to remove it when unstable warnings become useful.

CC @alexcrichton

[steveklabnik]

We had some discussion about this at the core team meeting, and have a plan for moving forward here. You're totally correct that the current situation isn't as useful as it could be.

[alexcrichton]

This is actually covered by #20445 as the plan is to remove allow(unstable) altogether in favor of naming selective features that you would like to opt in to. For example most programs would today have #![feature(io, path)] to allow usage of the std::io and std::path modules (a significant number of the warnings today). The general idea is that with that stability attribute infrastructure programs can selectively opt-in to features on a case-by-case basis instead of blanket allowing all unstable features.

The warnings today can generally be categorized into "expected instability" and "unexpected instability". We expect warnings on usage of the io module, for example, but we do not expect warnings on the usage of .to_string(). We would like to be notified about APIs that we need to stabilize during the beta cycle, and the warnings are meant to serve as a catalyst for that.

I think regardless though I'm going to close this in favor of #20445 as it will largely become obsolete after that.

[SimonSapin]

Hopefully #20445 is fixed soon :) (I realize that’s easy to say when I’m not doing the work.) If you expect it to be, let’s say, weeks rather than days, would you consider reverting warn(unstable) in the meantime?

[alexcrichton]

I believe @brson is implementing the new feature infrastructure, so he may be able to give you a better estimate on the time span.