Couple of thoughts, sorry for the scattershot reply but thereās not a common thread between them.
Features are supposed to be additive, so a feature to disable parts of a crate doesnāt make much sense
By āfeatureā I just mean some flag for conditional compilation. Also, features can totally be used to disable compilation through #[cfg(not())] attributes, but thatās neither here nor there because Iām imagining a more native support than ājustā using the feature system.
Everything that belongs to a top-level crate is built no matter what (otherwise main() would have to be #[stable], for example).
If you feel that main needs to always be built, Rust already has an internal notion of the āmainā function, and you could just always build that item. Though with #[cfg(not())], you could conditionally fail to compile main today & I donāt see that as an inherent problem. More importantly, I donāt think this attribute should be aware of which module it is in.
I donāt see why a binary would ever be compiled with the āstable onlyā feature activated, but I think that ties into my next comment.
By default, dependencies only have their stable and unspecified items built.
There are a few different definitions of āby defaultā - what rustc does by default and what cargo does by default.
I think, by default, rustc should ignore these attributes. But rustc can accept flags which control how it interprets stable/unstable/absent attributes.
I think there are a couple of different valid default options for cargo. What youāve said is one of them, but hereās another (Iāve no strong opinion about which is better):
cargo does not pass any argument to rustc by default; by default this system is ignored. A crateās Cargo.toml, though, can have an attribute indicating that it is using stability attributes; if it has that attribute that means that when compiling it as a dependency, only stable items should be compiled (not untagged items).
Rust gains a new extern crate attribute, #[unstable_use], which is basically #[macro_use] but for unstable items.
Iād much rather this be an attribute you add to your declaration of that dependency in Cargo.toml, not an attribute to the extern crate declaration. But the principle is the same.
rustc does not gain awareness of crate stability. Instead, Cargo is responsible for ensuring that >= 1.0.0 crates are sound (i.e. contain either no publically-visible items, or at least one publically-visible stable item; eventually unspecified items will be banned as well).
I donāt like this part of the RFC at all - I donāt think crates should be compelled to use this system. Iād much rather the situation be that crates can choose to use this system, in which untagged items are treated as unstable.
Long story short: if an item is #[deprecated], itās now recognised as being unstable in addition to being recognised as deprecated (but rustc only warns about the item being deprecated). I agree that the text should be clearer about this.
This isnāt consistent with how deprecation works in std. In std, if an item is deprecated, it is still āstable,ā it just emits a deprecation warning.
