> This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release.
Easy example of a basic method that has been unstable for a really long time: [T]::as_slice [0] since 2024 [1]. Apparently, stabilization was attempted earlier this year [2] but was then rolled back [3]. While clearly it was not yet ready for stabilization, it still took over a year before the first attempt.
Another one: Option::zip_with [4] since 2020 because nobody's figured out if it's worth having over .zip(...).map(...). Option::zip was actually stabilized [5] later in 2020 but Option::zip_with has since been sitting in limbo for over five years.
Another one: <*const [T]>::as_ptr also since 2020 [6]. I can't remember if there's an alternative now but dealing with slice pointers without relying on unstable methods has historically been very difficult/annoying. I ran into a bunch of this kinda stuff while working on a crate for iterating over rows/columns of image buffer subregions, because I wanted to use and support slice pointers. (Specifically I think getting the length of the slice pointer was nearly impossible without invoking UB, because constructing a reference (which was the only safe way to access a len method) could break aliasing rules. However I think the len method on slice pointers was stabilized a while ago so that particular problem is no more.) Speaking of which, <*mut [T]>::split_at_mut has been unstable since 2022 [7]...
I'm not saying there's no reason for any of this, just that as a Rust developer it's been frustrating. There are enough of these all over the place that it feels like a real occurring problem, even if it's not reasonable to expect a volunteer open-source project to pay full attention to everything ever.
[0]: https://doc.rust-lang.org/std/primitive.slice.html#method.as...
[1]: https://github.com/rust-lang/rust/issues/130366
[2]: https://github.com/rust-lang/rust/pull/151603
[3]: https://github.com/rust-lang/rust/pull/152963
[4]: https://github.com/rust-lang/rust/issues/70086
[5]: https://github.com/rust-lang/rust/pull/72938
[6]: https://github.com/rust-lang/rust/issues/74265
[7]: https://github.com/rust-lang/rust/issues/95595
> Can't you tell it to use stable as the default target, and use nightly manually in cargo?
Are you saying it doesn't suggest unstable features when using a stable toolchain? That was not my experience before I started using nightly.
> Are you saying it doesn't suggest unstable features when using a stable toolchain? That was not my experience before I started using nightly.
Oh really? I've never used any Jetbrain product so I don't know but if it's indeed the case even when you don't even use a nightly toolchain that sounds like a very bad design.