> but is still unstable due to being "newly added".
Where did you get this from? The tracking issue says nothing of the sort: https://github.com/rust-lang/rust/issues/61695
Where did you get this from? The tracking issue says nothing of the sort: https://github.com/rust-lang/rust/issues/61695
That issue had been filed by its OP as a feature request. It then got repurposed into a tracking issue for the feature, but it's not following the standard tracking issue template that lists any blockers, stabilization steps, etc. (Compare to https://github.com/rust-lang/rust/issues/119364 that happens to be the newest "Tracking issue" atm.) Also since the OP didn't intend for it to be the tracking issue, it's possible they're not intending to do the rest of the bureaucracy to get it stabilized either, which is why it's stalled.
It absolutely was, but now it seems to be mostly that the stabilization process is tedious enough that nobody has done it yet for this tiny utility function. There are tens of other tiny utility functions in the same situation that have been sitting for years, I run into them all the time.
The whole situation surrounding "unstable features" is just super disappointing for me. This stuff doesn't deserve to be unstable, and I shouldn't have to switch to an experimental toolchain that breaks all the time just to use these tiny utility functions!
No, there is no such absolute requirement that "newly added" functions cannot be stabilized. Off the top of my head: https://github.com/rust-lang/rust/issues/111544 `OsStr::as_encoded_bytes` was proposed in 2023-05, finished being implemented in 2023-07, stabilized in 2023-09, and released in 2023-11.
>https://news.ycombinator.com/item?id=38801228
The reason attr of "newly added" is the reason to *mark the function unstable* when it was implemented. It's not the reason to *prevent it from being stabilized.*
I never said so.
The source code?
#[unstable(feature = "unwrap_infallible", reason = "newly added", issue = "61695")]
Your comment said:
> `Result::into_ok`, which was introduced in 2019, but is still unstable due to being "newly added".
Your comment makes it sound that the Rust team considers a four year old utility method as "newly added", and that's the reason why this method is marked as unstable. More likely, this "newly added" reason is something they add for any new unstable feature, and it is now out of date.
Considering that repository has 9,000 open issues, and 50,0000 total issues, you can imagine that this issue has simply not been prioritized. Rust being poor at prioritizing, handling issues, etc. is a totally separate discussion from "Rust thinks four year old code is new"
[0]: https://github.com/rust-lang/rust/commit/c784720f3a2d0b66142...
This is just a process error, IMHO. The process for stabilization in general just results in outliers like this and it's really frustrating for everyone involved. I know Rust is sort of unique here, just like it's unique in all sorts of other ways, but I can't help but think that there could have been some sort of provision for small methods like these.