I feel #98905 is a molehill into mountain topic, and hesitated to further that by posting this, but the topic was presented as concerns over the wider issue of stability, which I do care about quite a bit.
So even though it was brought up as an example, I would love to hear your take as a library team member on proposals like that in #98905 more generally. Namely,
- Is it the case that an implementation of a trait will never be removed from
std? - If not,
- What is the bar for making such a breaking change?
- How does that gel with the guarantee of RFC 3085 to not split the ecosystem, and with Rust's backwards compatibility guarantees more generally?
I wish I didn't even have to ask this, but I've seen too many instances of [1] breaking changes [2] and RFC reversals at this point not to. I don't think the example in particular is likely to go anywhere [3], but would love some more clarity on what direction Rust is heading with regards to stability more generally.
As is readily apparent from the above, I am one of those people who values backwards compatibility -- or more generally stability -- more than achieving perfection in the language. It is true that every break and churn presents a new challenge when advocating for Rust in a professional (practical) setting. However, economics is not why I value stability so highly. I feel the way I do because I too 
Rust and want it to continue on its path of success; to not only be a language I'm still using decades from now, but to be a common one which has supplanted others, and is considered a good and reliable choice. And in my opinion, stability is a vital quality necessary for this to happen, not a boogyman.
Moreover, I don't believe in an unflawed language (or standard library) [4] any more than I believe in complete and consistent mathematical system [5]. We will never reach perfection. [6] I do not like the existing warts [7], but I will take them over breakage. There are even "features" and warts that bug me enough I sometimes daydream of a Rust 2.0 [8], but as I cannot imagine Rust surviving such a split today any more than it could survive instability, a dream is all it is. My desire for Rust's success far outweighs the annoyances, and thus we live with the warts. [9] I would rather the minor problems, and Rust itself, live forever [10] than for both to go away [11].
Being unable to rely on Rust being stable was also a problem -- one that was supposed to end with 1.0.0.
-
or advocates for ↩︎
-
or at least nowhere as extreme as proposed so far ↩︎
-
that is also powerful enough to be useful ↩︎
-
that can perform arithmetic or more ↩︎
-
Higher-ranked inference is apparently undecidable, as an example for those who prefer concrete reasoning. ↩︎
-
and have my own laundry-list of things I wish were different ↩︎
-
or time-travel fixing them ↩︎
-
And thus it's vital to advocate for the language you want at the RFC, FCP, and similar pre-stabilization stages. ↩︎
-
from my mortal point of view ↩︎
-
or into obscurity ↩︎