rfcs
rfcs copied to clipboard
Stability attribute for library authors
Rust needs an #[unstable] attribute for library authors to use, similar to the #[unstable] attribute used by the standard library.
I expect much of the reasoning for this could be based on https://github.com/rust-lang/rfcs/pull/1270 (#[deprecated] for Everyone
)
A huge :+1: for this from me. I miss this feature. I think everyone agrees it's wanted, I'm not 100% sure what all the open questions are, and why it was removed prior to 1.0. I do recall the argument being that the current system was designed for std
but I'm not sure what would need to change.
I am really wandering why all #[stable]
, #[unstable]
and #[deprecated]
flags were removed from Rust 1.0. All of them were really usable in real world libraries to mark which segments of API are still prone to change and which are already set.
It's as the above comment said; the current ones were designed for the needs of the compiler, but the ecosystem has different needs.
On Tue, May 31, 2016 at 8:52 AM, Łukasz Jan Niemier < [email protected]> wrote:
I am really wandering why all #[stable], #[unstable] and #[deprecated] flags were removed from Rust 1.0. All of them were really usable in real world libraries to mark which segments of API are still prone to change and which are already set.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rfcs/issues/1491#issuecomment-222678860, or mute the thread https://github.com/notifications/unsubscribe/AABsisG0gwbGApx_YdRyhBzyG92yP698ks5qHC7ygaJpZM4HUyZS .
I'd like to see this as well. In particular, I'd like to see this with support for version markers, to make it easier for tools to say "what version of this crate do I need based on the features I use".
A general solution would be great in conjunction with #1133.
There's this "pre RFC": https://internals.rust-lang.org/t/pre-rfc-crate-item-stability/4425/12 (rendered).
It would be nice to see some progress on this. Rather than an #[unstable]
attribute it would make more sense to me if only items marked #[stable]
would be considered stable, and Cargo would get some new functionality to allow opt in/out of stability checking for the whole crate and per dependency.
Edit: maybe I'm slow, but I realise we don't necessarily need a new compiler feature. We already have features so can do #[cfg(feature="unstable")]
or more fine grained control with individual features.
Is any work done on this?
I've created this experimental proc-macro to somewhat mimic this behavior suitable for libraries: https://docs.rs/stability/0.1.0/stability/attr.unstable.html. Not as good as the real deal but hopefully almost as useful.
Any perspectives on this?
Put me in coach!