Is there a way to get notified when feature becames stable?

[In-line]

In my personal projects I use stable compiler and prefer not to switch to nightly. There are few lines in my code like this:

// TODO: Use foo, when foo becames stable /*link to github*/
// Commented code

I usually use some workaround before feature becames stable. Is there an annotation or something which will give me warning, when feature became stable and encourage me to update my code?

It seems for me, good addition to have.

[nagisa]

Subscribe to the corresponding C-tracking-issue issues.

[nagisa]

Oh and the Rust compiler will warn for most features that have been stabilised but still have a corresponding unnecessary #![feature(...)]. Example.

[In-line]

Hey, thanks for the response, but IMHO I don't agree with the idea of closing this issue.

1. Subscribing to the C-tracking-issue issues and manually checking code for updates is a bad idea. I'm asking about automatic solution.
2. I don't use nightly and code requiring feature in the most cases isn't written. A workaround is used.
3. This is the example, hypothetic use of the annotation I desire.

#[maybe_feature(some_feature)]
fn example() { /*....*/ }

Prints nothing on stable, when feature becames stable it prints.

Warning: the feature `some_feature` has been stable since 1.26.0```

[In-line]

Friendly ping @nagisa

[abonander]

Subscribe to the corresponding C-tracking-issue issues.

Given how much discussion can occur in some of these tracking issue threads, this is probably too noisy to be useful for someone who's just interested in the stability status.

I second using the feature flag to watch the status but it'll really only provide consistent updates if you're testing the project in CI, otherwise you have to remember to build under the nightly compiler from time to time if you prefer stable like @In-line. You can use cfg_attr and a Cargo feature so that it doesn't always require nightly at least:

// `nightly` is not a special feature name but it's sort-of the convention
#![cfg_attr(feature = "nightly", feature(...))]

You can also add #![deny(stable_features)] to trigger a lint error for stabilized features so it "breaks" the build and notifies you (if you have Travis-CI set up to do that).

Travis-CI will build open-source projects for free regardless of if they're published on Crates.io. It's relatively easy to configure as well. Here's a basic .travis.yml assuming you're using nightly as your Cargo feature for this:

language: rust
rust:
  - stable
  - nightly
matrix:
  # this prevents the entire repostory's build status from being marked as failed
  # it depends on whether you want stabilized features to loudly notify you or not
  - allow_failures:
      - rust: nightly
script:
  - cargo build --verbose --all
  - cargo test --verbose --all
  # this is how we test the `nightly` feature
  - if [ ${TRAVIS_RUST_VERSION} = "nightly" ]; then cargo build --features "nightly"; fi

[abonander]

For closed-source projects, if you use Rustup you can set your default compiler to stable and then add cargo +nightly build --features "nightly" to your post-commit hooks.

You could even have a separate dummy Cargo project that just specifies these features and runs cargo +nightly build in a regular cron job or something. You could even just have this one set to build on Travis-CI if you want. You can even forget cfg_attr, just have Travis build exclusively on nightly:

language: rust
rust:
    - nightly

I also recommending subscribing to This Week in Rust which summarizes updates on tracking issues and RFCs, but it doesn't actually report when a tracking issue is closed due to a stabilization. No idea why.

[In-line]

Thanks, for provided solution, but I don't like idea of relying on nightly builds, because they can fail. I'm sticking with the opinion to have dedicated annotation for this thing.

[hellow554]

Reading the release notes also helps 😶

[estebank]

It could make sense to have a dashboard view that collects the stability information for all features, as we already collect in the code meta information about stability state, since which version and tracking ticket information in order to provide error diagnostics. Having an analogous page to the Error Index for features makes sense to me.

[jonas-schievink]

Instead of subscribing to the tracking issue, you can also use https://tellmewhenitcloses.com to get one email when the issue is closed (which happens when the feature is stabilized).