If the majority of the modules are already stable, why not wait until they are marked as stable, with a more realistic set of #[unstable] in the standard library for the alpha release?
Anyone using the alpha now is being smashed with pointless unstable warnings until they add #![allow(unstable)]
...which basically negates the point of having the lint at all.
Surely a better approach would be; if 'we have no idea where it's at at the moment', don't tag the api as unstable. Tag things which wont make it into 1.0 as unstable, so people start getting meaningful warnings about using api features that won't make it into 1.0.
Seriously, what tangible benefit do 90 warnings about every single api have when you run a compile?
Even if that number slowly drops over the coming weeks, it's still going to be entirely meaningless as an indicator of what will or will not be broken once the beta hits; you're also going to be getting a lot of rubbish feedback from people asking for certain apis (which will be stable for 1.0) to be stable, because of warnings that they're unstable; for example std::fmt.
...while anyone using say, std::raw::TraitObject, or say, alloc::heap::allocate, needs to get a heads up now that they needs to say something and get involved if they want those apis to make it into 1.0
Practically speaking, it feels like you need to roll back to 'unstable' and 'experimental' tags, with the lint warning about experimental, and ignoring unstable.
ie.
'unstable' <--- Probably in 1.0, not final yet, don't lint these.
'experimental' <---- wont be in 1.0, lint on these
Anyone using the alpha now is being smashed with pointless unstable warnings until they add #![allow(unstable)]
...which basically negates the point of having the lint at all.
Surely a better approach would be; if 'we have no idea where it's at at the moment', don't tag the api as unstable. Tag things which wont make it into 1.0 as unstable, so people start getting meaningful warnings about using api features that won't make it into 1.0.
Seriously, what tangible benefit do 90 warnings about every single api have when you run a compile?
Even if that number slowly drops over the coming weeks, it's still going to be entirely meaningless as an indicator of what will or will not be broken once the beta hits; you're also going to be getting a lot of rubbish feedback from people asking for certain apis (which will be stable for 1.0) to be stable, because of warnings that they're unstable; for example std::fmt.
...while anyone using say, std::raw::TraitObject, or say, alloc::heap::allocate, needs to get a heads up now that they needs to say something and get involved if they want those apis to make it into 1.0
Practically speaking, it feels like you need to roll back to 'unstable' and 'experimental' tags, with the lint warning about experimental, and ignoring unstable.
ie.
'unstable' <--- Probably in 1.0, not final yet, don't lint these.
'experimental' <---- wont be in 1.0, lint on these