When should we start stabilizing libraries?

[sinistersnare]

Hey, we have recently been going on to adding stability attributes to multiple crates. Most of these attribute are #[unstable], but I would like to know the policy for library stabilization.

Features like higher kinded types and variadic generics are on the post-1.0 horizon, however these features can vastly simplify libraries when created. Everyone knows (hopefully) that the 1.0 goal is to create an extremely solid base of a language and then work out from there, however what I see no conversation of is library stabilization.

TL;DR: What is the strategy for library stabilization with post 1.0 features like HKTs and variadic generics on the radar?

[cmr]

The core team has been meeting weekly to review various APIs in the distribution for stabilization or changes. We mark stable that which we are confident in, or leave notes as to why something is at a given stability level. So the policy is “what the team agrees is best”, more or less. Portions of the stdlib in need of language features probably just won’t be stabilized. Avoiding an obligation to a crappy stdlib is something everyone is aware of and working towards.

[sinistersnare]

That makes sense, is the core team planning on waiting for features like HKTs to add to the APIs? I hear that Monads and such could simplify and unify types like Option and Result.

[steveklabnik]

The improvements that HKT would bring to Option and Result would be additional interfaces, so that doesn’t really play a part in terms of stabilizing the existing one.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.