Stabilization metabug: 1.0-alpha #19260
Comments
|
cc @alexcrichton @brson @nikomatsakis @huonw @pcwalton @alexcrichton, can you populate the non- Everyone: please help me fill in the "Feature stabilization" section. |
|
A note about the 1.0.0 beta period: we are planning to run at least two beta cycles. During the first cycle, we plan to turn on the stability lints, but not to add the The second cycle will then add By the time we release the first beta, we expect the bulk of By the second cycle, there should be very little large-scale API revision. Thus, the two cycles should serve as a period of relative calm (compared to today's very rapid breakage) during which the crates.io ecosystem can stabilize and grow before the stable 1.0 release. |
|
cc me |
This commit deprecates a few more in-tree libs for their crates.io counterparts. Note that this commit does not make use of the #[deprecated] tag to prevent warnings from being generated for in-tree usage. Once #[unstable] warnings are turned on then all external users will be warned to move. These crates have all been duplicated in rust-lang/$crate repositories so development can happen independently of the in-tree copies. We can explore at a later date replacing the in-tree copies with the external copies, but at this time the libraries have changed very little over the past few months so it's unlikely for changes to be sent to both repos. cc rust-lang#19260
This commit deprecates a few more in-tree libs for their crates.io counterparts. Note that this commit does not make use of the #[deprecated] tag to prevent warnings from being generated for in-tree usage. Once #[unstable] warnings are turned on then all external users will be warned to move. These crates have all been duplicated in rust-lang/$crate repositories so development can happen independently of the in-tree copies. We can explore at a later date replacing the in-tree copies with the external copies, but at this time the libraries have changed very little over the past few months so it's unlikely for changes to be sent to both repos. cc rust-lang#19260
|
Default type parameter (RFC 213) should be in the feature stabilization list. |
|
I've updated the list and added |
cc #19260 The casing transformations are left unstable (it is highly likely to be better to adopt the proper non-1-to-1 case mappings, per #20333) as are `is_xid_*`. I've got a little todo list in the last commit of things I thought about/was told about that I haven't yet handled (I'd also like some feedback).
cc #19260 Open questions: - I still feel weird about marking functions like `exp` as `#[stable]` in `core` since they're highly likely to call into libm which is theoretically something core is designed to avoid and so we may be forced/want to move it at some point in the future, and so it feels like a lie to call it `#[stable]` (I know `core` is `#[experimental]`, but still...) - `abs_sub` is a horrible name IMO: it feels like it is `(a - b).abs()`, but it is actually `(a - b).max(0.)`. maybe something along the lines of `pos_diff` ("positive difference") is better. - the associated-function nature of `Int::from_be` and `Int::from_le` feel strange to me, it feels like they should be methods, but I cannot think of a good name. I'm also not hugely in favour of `ldexp` and `frexp` but the precedent from C is large. (e.g. AFAICT, `ldexp` must mean "load exponent" which is essentially what it does... but only for a subset of its inputs.)
|
I've renamed this to stabilization for 1.0-alpha, which is complete. There's a new issue for 1.0-beta. |
This is a tracking metabug for stabilization of both APIs and gated features.
API stabilization for
libstdFirst pass stabilization/reform
For simpler/mostly stable APIs (core types, iterators), stabilization is mostly a matter of aligning with conventions and deprecating marginal methods and takes place directly under the supervision of the core team. For deeper redesign, RFCs are needed. Where applicable, the list below points to the relevant RFC.
Most APIs with a chechmark are still
#unstable, either due to developing conventions, lack of language features (e.g. unboxed closures), or some other problem. We plan to do a rapid second pass closer to the 1.0.0 beta.(You can track the following list quantitatively, though the fact that trait impls count exaggerates the amount of
#[experimental]items.)Items are marked complete when a PR/RFC has been posted -- this is just tracking the design work.
any- std: Stabilize unit, bool, ty, tuple, arc, any #15936ascii(see RFC)bitflags(see RFC)bool- std: Stabilize unit, bool, ty, tuple, arc, any #15936borrow(see RFC)boxed- Stabilization forowned(nowboxed) andcell#15591c_str(see RFC)c_vec(see RFC)cell- Stabilization forowned(nowboxed) andcell#15591char- Some stabilization and conventions changes to std::char #18603clone- core: Add stability attributes to Clone #15135cmp- Stability for core::cmp, core::default, alloc::rc, std::task #15797 (see RFC)collections(see RFC)comm- Apply stability attributes to std::comm #15286default- Stability for core::cmp, core::default, alloc::rc, std::task #15797dynamic_lib(#[unstable])error(see RFC)f32,f64(see RFC)finally(#[unstable])fmt(see RFC)hash- std: Stabilize the std::hash module #19673i8,i16,i32,i64,int(see RFC)intrinsics(#[unstable])io(see RFC)iter- libs: stabilize iter module #19176kinds(punted to second pass)thread_local(see RFC)macros(punted to second pass)mem- core: Finish stabilizing thememmodule. #14392num(see RFC)ops(see RFC)option- stabilize core::{option, result} #16664os(see RFC)path(see RFC)prelude(see RFC)rand(#[unstable])raw(#[unstable])rc- Stability for core::cmp, core::default, alloc::rc, std::task #15797result- stabilize core::{option, result} #16664rt(#[unstable])simd(#[unstable])slice- Cleanup and stability for core::slice #16332str- std: Stabilize the std::str module #19741, (see RFC)string- collections: Stabilize String #17438sync- std: Rewrite thesyncmodule #19274task(see RFC)time(punted to third pass)tuple- (likely to be deprecated before 1.0), std: Stabilize unit, bool, ty, tuple, arc, any #15936u8,u16,u32,u64,uint(see RFC)unit- std: Stabilize unit, bool, ty, tuple, arc, any #15936vec- collections: Stabilize Vec #17029Second pass stabilization: for alpha
The second pass is about actually moving APIs to
#[stable]status; it may involve a bit of minor shuffling, but any major design work should have already taken place. In many cases APIs were blocked on language features (like unboxed closures) before moving to this status.any#[unstablefor alpha)ascii#[unstable]for alpha)bitflagsbool- acrichto std: Remove public bool,tuple,unit modules #20006borrow#[unstable]for alpha)boxed- acrichto std: Second pass stabilization forboxed#20420c_str- acrichto std: Redesign c_str and c_vec #20507c_vec- acrichto std: Redesign c_str and c_vec #20507cell- aturon Stabilize cell #20066 --stdmodule mistakenly left experimentalchar- huonw Second stabilisation pass of*::char#20395clone- aturon Stabilize clone #20070cmp- aturon Stabilize cmp #20065collections- aturon / @gankro stabilize more of collections #20356comm- acrichto std: Second pass stabilization forcomm#20273default- acrichto std: Second-pass stabilization ofmem/default#19902dynamic_lib#[unstable])error- aturon Stabilize std::error #20647f32,f64- aturon (note: already stable; thenum::Float/FloatMathtraits are the problem point)finally#[unstable])fmt- acrichtohash- acrichto std: Stabilize the std::hash module #20654i8,i16,i32,i64,int- aturon Stabilize integer modules #20062intrinsics#[unstable]for alpha)io#[unstable]for alpha)iter- aturon Final pre-alpha stabilization of: iter, ops, slice, collections #20560kinds- aturon/nrc, flatten tomarkersChangestd::kindstostd::markers; flattenstd::kinds::marker#20607macros- acrichto std: Stablize the macros module #20657mem- acrichto std: Second-pass stabilization ofmem/default#19902num- aturon/huonw Second stabilisation pass of*::num#20573ops- aturon Final pre-alpha stabilization of: iter, ops, slice, collections #20560option- acrichto std: Fully stabilize Option<T> #19849os#[unstable]for alpha)path#[unstable]for alpha)prelude- acrichto std: Stabilize the prelude module #20157ptr- acrichto std: Second pass stabilization forptr#20042rand#[unstable]for alpha)raw#[unstable]for alpha)rc- aturon (complete from pass 1)result- acrichto std: Second pass stabilization of Result<T, E> #19961rt#[unstable])simd#[unstable])slice- aturon Second pass stabilization: slice and vec #20061, Final pre-alpha stabilization of: iter, ops, slice, collections #20560str- acrichto std: Stabilize the std::str module #19741 / kimundi WIP Partially stabilizeStrExtfor pattern-using methods #20058string- acrichto std: Second pass stabilization forstring#20306sync- acrichto std: Return Result from RWLock/Mutex methods #19661, std: Second pass stabilization of sync #20315task(#[deprecated])thread- aturon Stabilize std::thread #20615thread_local- acrichto std: Second pass stabilization for thread_local #20354thunk#[unstable])tuple- acrichto std: Remove public bool,tuple,unit modules #20006u8,u16,u32,u64,uint- aturon Stabilize integer modules #20062unit- acrichto std: Remove public bool,tuple,unit modules #20006vec- aturon Second pass stabilization: slice and vec #20061RFCs for reform
The following RFCs tackle deeper API redesigns:
Accepted
ShowPending
Non-
stdcratesSee #18585 (comment)
Just need
#[experimental]We will ship these crates, but will they will participate in
#![staged_api]and will not be accessible in the stable channel.
Need
Cargo.tomland a publishing strategyThese crates will all be distributed, but participate in
#![staged_api]. Thismeans they will not be accessible in the stable channel's standard
distribution, but they will all be available through crates.io.
Need cooperation with the standard library due to compiler internals
Removed or to remove
std::taskwithstd::thread, remove librustrt, make final "runtime" features lazily initialize #19654Feature stabilization
Ungating
if let,while let, and tuple indexing #19472if let/while let(RFC), Remove feature gates forif let,while let, and tuple indexing #19472Removal
opsreformCLI Tooling
The text was updated successfully, but these errors were encountered: