I am experimenting the creation of a struct S to be used in the syntax for s in s1..s2
traits Step+Clone+PartialOrd are required
However, when trying to implement the trait Step, I just get
error[E0658]: use of unstable library feature 'step_trait': recently redesigned
Even switching to nightly or 1.8.0, I can't make it compile.
What am I supposed to do ?
You need to use the unstable #![feature(step_trait)] feature gate on a nightly compiler to implement the trait.
The Unstable Book doesn't have any useful information for it, but it does link to the same tracking issue: Tracking issue for step_trait stabilization · Issue #42168 · rust-lang/rust (github.com)
FWIW, 1.8.0 is very old (2016). You should read that middle number as a literal 8, which is much smaller than 76.
Ok, but what If I want to implement Range<S> with rust 1.76 stable ? Why does the doc leads me to an unstable trait Step if I can't use it ?
You are obviously right, my mind read 1.80 in that "rustup help update" output
Toolchain name, such as 'stable', 'nightly', or '1.8.0'. For more information see
`rustup help toolchain`
It is not possible. Feature gates only work on nightly.
It helpfully notes that it's feature gated. But unhelpfully (I have been tripped up by this, as well) doesn't really make feature gate discovery easy. It's just assumed that readers are already familiar with these concepts.
It makes it easy to discover unstable APIs, which I think is better than hiding them by default.
Ok, I though that the step_trait was deprecating something else that I could still use, but it means here that currently (1.76), customizing a Range<S> has never been a stable feature.
Your interpretation is correct! I do not believe that stable features ever become unstable. It's the other way around; unstable features eventually stabilize or are removed (without breakage, since unstable features are by definition not usable on stable compilers).
Deprecations look different in documentation. Here's an example: LinesAny in std::str - Rust (rust-lang.org)
In full disclosure it is possible to use unstable features on stable compilers by cheating with nightly-crimes but it is highly advised that you stay as far away from this as you can. 
I'd say there are 2-3 diagnostic failures here.
This would lead you to try to implement Step even though you can't do so on stable.
"recently redesigned" isn't why it's unstable, and was a poor choice of words. That has been the diagnostic "reason" for the trait being unstable since a redesign of the feature made four years ago. Even when it was recent, those on stable don't need to care about it being redesigned.
Very generally, trying to use something on unstable doesn't tell you about the feature gate (because you can't use it on stable). If I want to try it out, this is where I sigh, try again on nightly, and copy-paste the #![feature(_)] suggestion. (Still better than the cases that have a feature but don't tell you what it is.)
Granted, the expanded error text does mostly explain this. It doesn't tell you how to find the feature gates. Other than that I'm not sure there's a great way to improve this (that wouldn't e.g. lead to people trying #![feature] on stable).
That would be on me, I suppose, since I championed said redesign and set the reason string. In my defense, it made some sense at the time, when we required reason strings for all unstable features where a lot of them were just unstable with the only reason being everything gets introduced as unstable, and there was some hope at the time for stabilizing the trait[1]. IIRC, we've since dropped the requirement to have a reason string because most weren't actually useful, so it should probably be removed from the step trait feature gate.
That's why I had split the feature gate into two for the checked and unchecked parts, while it's been recombined now. ↩︎
I agree, the reason (and the previous reason, and probably a lot more existing reasons) made a lot more sense when the perspective was "we'll surely stabilize this any day now" (and when the audience was more likely to be aware of, and eagerly awaiting, accepted features under development).
/me thinks back to wanting some way or another to do very basic OsStr checks and operations, any day now... ↩︎
(as_encoded_bytes landed in 1.74) ↩︎
I've made a PR to improve the docs thanks to this.
And, uh... found a UB. That's an oopsie 
(checks git blame: me)
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.