This is what I imagine the story to be behind a lot of things that were stripped pre-1.0 like std::num::Zero.
Stabilization affects the language
At some point in time, the feature existed. However, there were things about it that were simply not as nice as it could be:
- perhaps the best design was still unclear; it needed further experimentation and design iteration.
- perhaps rust was missing critical language features to make it ergonomic (or these features existed and were buggy/unreliable), like
constfunctions or higher ranked types.Zeroappears to have been such a trait; its unstable feature message used to read:Unstable: unsure of placement, wants to use associated constants
- if something was underutilized there could be unknown unknowns; poor design decisions lurking just beneath the surface that would only be discovered after stabilization. (and even with the team practicing their discretion, some of these still managed to slip through, like
std::error::Error)
In the rush to 1.0, a decision had to be made:
Are we ready to support this thing in its current form, without breaking changes, for all of eternity? Or should we wait until it is possible to do better?
Some things (like the f64::consts modules) were simply so fundamentally important that something had to be stabilized even if it was a terrible hack! But many things were hidden behind feature flags on the notion that we can have something better.
For a while after the 1.0 release, you couldn't even sum an iterator on stable!! Things such as this were slowly added back based on how desparately they were needed. There wasn't a single person using rust who was not losing hair over the inability to sum an iterator, so std::iter::Sum eventually had to be added even despite being a terrible hack.
So that's my idea of how these features got removed. However, there is also a second chapter to this story.
The language affects the users
After the removal of something from the standard library, a paradigm shift can occur. People can go from thinking
this is basic functionality and it is appalling that I need to use a third-party crate
to beginning to think
that problem is so complicated that it doesn't even belong in the standard library. There is no design that is good enough to be worthwhile.
Maybe sometimes this really is true, but other times this view may simply by colored by the status quo. In a way, it's the blub effect, and I believe we are all susceptible to this.
I know I'm going to receive flak for saying this, but:
We are all at risk of adopting an apologist viewpoint on missing features.
...and it is at this point that the absence of something in the standard library may become self-sustaining.
How can this be prevented? I don't know. Identifying and challenging one's own cognitive biases is not easy. Sometimes somebody motivated appears and smacks whole the rust community with a harisen, writing an epic blog post to remind us all that yes, there is still hope for having such a feature in the standard library. But in general?
...hm, there I go again. Always seeing the problem, but never the solution...
I had an example of a possible personal case of this phenomenon, but it has gotten really long for this post. Maybe I'll make a separate thread...