Decide on (and implement) which parts of the AST can get stability attributes

[huonw]

As of #8921, the compiler checks the attributes on structs, enum variants (not enums themselves) and functions. Definitely required: methods (#8961) and mods (#8962).

Up for discussion:

• traits
• enums
• impls (both impl Type and impl Trait for Type)
• struct fields
• type aliases.
• foreign fns
• anything else that can take attributes in the ast

(Part of #6875.)

[brson]

Anything that might be named should probably have stability levels. From your list the two that I see that might not need them are fields (stability can apply to the entire struct) and impls (methods may be enough).

Traits are important and especially tricky though, since there are multiple ways for them to be used. It would be great if calling trait methods and implementing traits could be considered separately. As long as the trait has a stable name, and you don't implement the trait, then just calling a method doesn't require all methods on the trait to be stable. Hard to represent all that subtlety though. If we can't then basically you have to declare an entire trait stable at once, which will make stabilizing things like str and vec pretty tough - I can foresee traits like OwnedVector2, OwnedVector3 in our future.

[huonw]

I was assuming that trait methods would be checked (presumably only annotations on the original trait, otherwise it will act differently for generics and concrete types), and that it would be useful to mark trait impls, i.e. "don't use this trait on this type"; although, to be 100% useful, it would have to check whenever it was used in a context that assumed this trait (i.e. generics, casting to a trait object, calling a method) which might be tricky.

[emberian]

Traits and enums definitely, but I don't think the rest are going to be useful.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#687