4 ms·

> It's been annoying to me as an end user that so many basic things require nightly It used to be the case a decade ago, but now I wouldn't agree that any "bas

by stymaar 2mo ago

> It's been annoying to me as an end user that so many basic things require nightly It used to be the case a decade ago, but now I wouldn't agree that any "basic" things require nightly (I wouldn't call portable SIMD "basic" at all for instance). > Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! 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. The 6-weeks release cadence with beta in between means there's always at least 6 weeks and up to 3 months between the time a feature land on nightly and the day it reaches stable, even if the feature is as consensual as this one. > And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. Can't you tell it to use stable as the default target, and use nightly manually in cargo?

LoganDark 2mo ago
> 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_slice https://doc.rust-lang.org/std/primitive.slice.html#method.as... [1]: https://github.com/rust-lang/rust/issues/130366 https://github.com/rust-lang/rust/issues/130366 [2]: https://github.com/rust-lang/rust/pull/151603 https://github.com/rust-lang/rust/pull/151603 [3]: https://github.com/rust-lang/rust/pull/152963 https://github.com/rust-lang/rust/pull/152963 [4]: https://github.com/rust-lang/rust/issues/70086 https://github.com/rust-lang/rust/issues/70086 [5]: https://github.com/rust-lang/rust/pull/72938 https://github.com/rust-lang/rust/pull/72938 [6]: https://github.com/rust-lang/rust/issues/74265 https://github.com/rust-lang/rust/issues/74265 [7]: https://github.com/rust-lang/rust/issues/95595 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.
- stymaar 2mo ago
  > 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.

by stymaar 2mo ago

LoganDark 2mo ago

> 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_slice https://doc.rust-lang.org/std/primitive.slice.html#method.as... [1]: https://github.com/rust-lang/rust/issues/130366 https://github.com/rust-lang/rust/issues/130366 [2]: https://github.com/rust-lang/rust/pull/151603 https://github.com/rust-lang/rust/pull/151603 [3]: https://github.com/rust-lang/rust/pull/152963 https://github.com/rust-lang/rust/pull/152963 [4]: https://github.com/rust-lang/rust/issues/70086 https://github.com/rust-lang/rust/issues/70086 [5]: https://github.com/rust-lang/rust/pull/72938 https://github.com/rust-lang/rust/pull/72938 [6]: https://github.com/rust-lang/rust/issues/74265 https://github.com/rust-lang/rust/issues/74265 [7]: https://github.com/rust-lang/rust/issues/95595 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.

stymaar 2mo ago
> 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.