4 ms·
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 qu
by singron 11mo ago
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.
- vlovich123 11mo ago> 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 11mo agoI 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.
- throwup238 11mo ago> 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.