4 ms·

> 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

> 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 https://github.com/rust-lang/rust/issues/61695

Arnavion 3y ago
Right, it's nothing to do with it being "newly added". 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 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.
- LoganDark 3y ago
  > Right, it's nothing to do with it being "newly added". 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!
  - Arnavion 3y ago
    >It absolutely was 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 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 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.*
    - LoganDark 3y ago
      > No, there is no such absolute requirement that "newly added" functions cannot be stabilized. I never said so.
      - Arnavion 3y ago
        You did, and it was already covered in https://news.ycombinator.com/item?id=38801686 https://news.ycombinator.com/item?id=38801686 so I'm not going to repeat it.
        shepherdjerred 3y ago
        Thanks for validating my comment. I thought I was going crazy in that thread.
LoganDark 3y ago
> Where did you get this from? The source code? #[unstable(feature = "unwrap_infallible", reason = "newly added", issue = "61695")] And that issue you linked is from 2019 and full of people asking when it will be stabilized. Last activity was in late 2021.
- shepherdjerred 3y ago
  That annotation hasn't been touched (aside from being moved around) since it was authored [0]. 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/c784720f3a2d0b66142da3c9a9fd6039f5d3a036 https://github.com/rust-lang/rust/commit/c784720f3a2d0b66142...
  - LoganDark 3y ago
    There's nothing wrong with their prioritization, there are tons and tons of high-priority issues that deserve more contributor time than this. Everyone's a volunteer. 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.

Arnavion 3y ago

Right, it's nothing to do with it being "newly added". 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 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.

LoganDark 3y ago
> Right, it's nothing to do with it being "newly added". 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!
- Arnavion 3y ago
  >It absolutely was 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 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 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.*
  - LoganDark 3y ago
    > No, there is no such absolute requirement that "newly added" functions cannot be stabilized. I never said so.
    - Arnavion 3y ago
      You did, and it was already covered in https://news.ycombinator.com/item?id=38801686 https://news.ycombinator.com/item?id=38801686 so I'm not going to repeat it.
      - shepherdjerred 3y ago
        Thanks for validating my comment. I thought I was going crazy in that thread.

LoganDark 3y ago

> Where did you get this from? The source code? #[unstable(feature = "unwrap_infallible", reason = "newly added", issue = "61695")] And that issue you linked is from 2019 and full of people asking when it will be stabilized. Last activity was in late 2021.

shepherdjerred 3y ago
That annotation hasn't been touched (aside from being moved around) since it was authored [0]. 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/c784720f3a2d0b66142da3c9a9fd6039f5d3a036 https://github.com/rust-lang/rust/commit/c784720f3a2d0b66142...
- LoganDark 3y ago
  There's nothing wrong with their prioritization, there are tons and tons of high-priority issues that deserve more contributor time than this. Everyone's a volunteer. 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.