There is a GitHub issue that details what's blocking stabilization for a each feature. I've read a few recently and noticed some patterns:

1. A high bar for quality in std

2. Dependencies on other unstable features

3. Known bugs

4. Conflicts with other unstable features

It seems anything that affects trait solving is very complicated and is more likely to have bugs or combine non-trivially with other trait-solving features.

I think there is also some sampling bias. Tons of features get stabilized, but you are much more likely to notice a nightly feature that is unstable for a long time and complex enough to be excited about.

▲

throwup238 11 hours ago | parent | next [-]

> It seems anything that affects trait solving is very complicated and is more likely to have bugs or combine non-trivially with other trait-solving features.

Yep and this is why many features die or linger on forever. Getting the trait solving working correctly across types and soundly across lifetimes is complicated enough to have killed several features previously (like specialization/min_specialization). It was the reason async trait took so long and why GAT were so important.

▲

vlovich123 12 hours ago | parent | prev [-]

> Dependencies on other unstable features

AFAIK that’s not a blocker for Rust - the std library is allowed to use unstable at all times.

	▲	estebank 12 hours ago \| parent [-]
		I think they meant on unstable features which might yet change their semantics. A stable API relying on unstable implementation is common in Rust (? operator, for example), but that is entirely dependent on having a good idea of what the eventual stable version is going to look like, in such a way that the already stable feature won't break in any way.