We can’t get rid of it because we have a commitment to not breaking users’ code. There will not be
a Rust 2.0.
This is interesting. The C Standard people have, for example, removed “gets” from the C11 standard.
Go, too, has exceptions to its Go 1 Compatibility Promise[1], which include security, unspecified
behaviour, and bugs, both in the language and in the standard library. I don't remember for sure,
but I think there were things removed from C++ specifications as well; please correct me if I am
wrong. Did Rust decided to never break stdlib compatibility because the mechanism of editions was
considered from the start, or was this rather ad-hoc?
We do reserve the right to make changes for soundness holes. In theory, you could argue that this is a soundness hole, and so we can remove it.
We have to do such things extremely judiciously though. Users can only tolerate so much breakage, even if you say “we did say we reserved the right to do this.” This API is just so rarely used that it was judged not a good time to pull the “technically we are allowed to do this” card.
C, C++, Common Lisp, and others have the benefits of an ANSI standard. Any compiler that says it supports the standard, supports it, regardless of compiler version or breaking changes in future standards. My C89 code will continue to work as long as a compiler supports that standard. Worse comes to worst, I can create my own implementation.
When you don't have a standard, you're left at the mercy of languages promising not to break stuff. If they do anyway, your options aren't as clean as just sticking to the older standard.
[1]: https://tip.golang.org/doc/go1compat#expectations