stable compiler should provide better advice for `Step` trait failures

[ericseppanen]

Code

fn custom_range() {
    struct Foo(u32);

    let x = Foo(0);
    let y = Foo(10);

    for value in x..y {}
}

Current output

error[E0277]: the trait bound `Foo: Step` is not satisfied
 --> src/lib.rs:7:18
  |
7 |     for value in x..y {}
  |                  ^^^^ unsatisfied trait bound
  |
help: the trait `Step` is not implemented for `Foo`
 --> src/lib.rs:2:5
  |
2 |     struct Foo(u32);
  |     ^^^^^^^^^^
  = note: required for `std::ops::Range<Foo>` to implement `Iterator`
  = note: required for `std::ops::Range<Foo>` to implement `IntoIterator`

Rationale and extra context

Users may encounter error messages saying some type does not implement the Step trait. These messages are not actionable, because the Step trait is unstable and in most cases there are limited options available to the user. This is hard to explain to beginners; if their mentor's explanation will be "yeah, that's kind of unhelpful; instead the error message should have said _____" then perhaps we could do better with the compiler diagnostics.

Instead of describing this as a typical trait failure, perhaps we should describe this as though it's an implementation detail of the standard library. This would avoid giving beginners the impression that they can somehow make it work if they knew the right syntax, which can be a frustrating experience.

Maybe the message should say something like:

`Range` only implements `Iterator` for select types in the standard library
(integers, `char`, and a few others).
To see the full list of types, see the documentation for the unstable `Step` trait.

I searched for other issues on this topic, and found it mentioned in #133511, which was resolved without providing any actionable help. The tracking issue for the Step trait is #42168. A few places where users have discussed it: 1, 2, 3, 4

Here are some additional examples where we might encounter errors mentioning the Step trait:

fn non_integer_range(x: f32, y: f32) {
    for value in x..y {}
}

error[E0277]: the trait bound `f32: Step` is not satisfied
  --> src/lib.rs:15:18
   |
15 |     for value in x..y {}
   |                  ^^^^ the trait `Step` is not implemented for `f32`
   |
   = help: the following other types implement trait `Step`:
             i128
             i16
             i32
             i64
             i8
             isize
             u128
             u16
           and 4 others
   = note: required for `std::ops::Range<f32>` to implement `Iterator`
   = note: required for `std::ops::Range<f32>` to implement `IntoIterator`

fn in_trait_bounds<T>(x: T, y: T) {
    for value in x..y {}
}

error[E0277]: the trait bound `T: Step` is not satisfied
  --> src/lib.rs:11:18
   |
11 |     for value in x..y {}
   |                  ^^^^ the trait `Step` is not implemented for `T`
   |
   = note: required for `std::ops::Range<T>` to implement `Iterator`
   = note: required for `std::ops::Range<T>` to implement `IntoIterator`

Rust Version

rustc 1.92.0 (ded5c06cf 2025-12-08)
binary: rustc
commit-hash: ded5c06cf21d2b93bffd5d884aa6e96934ee4234
commit-date: 2025-12-08
host: x86_64-unknown-linux-gnu
release: 1.92.0
LLVM version: 21.1.3

[estebank]

Output after #151036:

error[E0277]: `std::ops::Range<Foo>` is not an iterator
 --> f28.rs:7:18
  |
7 |     for value in x..y {}
  |                  ^^^^ `Range<Foo>` is not an iterator
  |
help: the nightly-only, unstable trait `Step` is not implemented for `Foo`
 --> f28.rs:2:5
  |
2 |     struct Foo(u32);
  |     ^^^^^^^^^^
  = note: `Range` only implements `Iterator` for select types in the standard library, particularly integers; to see the full list of types, see the documentation for the unstable `Step` trait
  = note: required for `std::ops::Range<Foo>` to implement `Iterator`
  = note: required for `std::ops::Range<Foo>` to implement `IntoIterator`

error[E0277]: `std::ops::Range<f32>` is not an iterator
 --> f28.rs:2:18
  |
2 |     for value in x..y {}
  |                  ^^^^ `Range<f32>` is not an iterator
  |
  = help: the nightly-only, unstable trait `Step` is not implemented for `f32`
  = note: `Range` only implements `Iterator` for select types in the standard library, particularly integers; to see the full list of types, see the documentation for the unstable `Step` trait
  = help: the following other types implement trait `Step`:
            i128
            i16
            i32
            i64
            i8
            isize
            u128
            u16
          and 4 others
  = note: required for `std::ops::Range<f32>` to implement `Iterator`
  = note: required for `std::ops::Range<f32>` to implement `IntoIterator`

Will there be any additional changes that you'd expect?

Personally, I think that both errors should display the list of implementers of Step (but that's a more general issue than just Ranges in for loops).

[ericseppanen]

@estebank wow, nice!

That looks pretty good to me!

The only concern I might have isn't very specific to this diagnostic: I think it's confusing to beginners when we say "something is wrong because ... nightly-unstable trait", because the follow-up question is "why am I getting errors about nightly/unstable when I haven't used either of those things?

I wonder if there should be a way of expressing that the unstable trait is being used to hide implementation details, sort of like a sealed trait in third-party crates. It would be nice to steer the beginner conversation away from the words "stable" and "nightly" toward some other concept or phrase that means "sorry, the current standard library does not have the flexibility you were looking for here".

As an example, if an error message said the internal trait `Step` is not implemented for `f32` , then I think it would be a lot less confusing.

Coining a new term sounds like overkill, but I don't know how else to teach the difference between:

1. Unstable but used in everyday code because it's how std implements internal details that are used by stable methods.
2. Unstable because it's a new unfinished feature under development that may never reach stable

[estebank]

Would it make sense to instead keep the labels/explanations "shorter" with the "unstable trait" wording (as that's the lingo that Rust uses everywhere, including documentation), and also add a note explaining something like "unstable traits are only available on nightly versions of Rust and can either be on track for stabilization or hide implementation details of the standard library". We could use that message anywhere we mention unstable items. We could also open a feature request for something like #[unstable(.., implementation_detail)] to differentiate between perma-unstable and things on track.

Keep in mind that part of the tight-rope act we're doing here is:

• being able to cater to people using nightly Rust, who want all this information and can enable the feature to use it
• not confuse newcomers who won't ever use nightly
• not be misleading to developers, library authors or std implementers
• provide enough context to someone who might be building a new crate that uses a recently stabilized feature being built on an older rustc

A lot of the time, these requirements are in tension with each other :-/

[ericseppanen]

Would it make sense to instead keep the labels/explanations "shorter" with the "unstable trait" wording (as that's the lingo that Rust uses everywhere, including documentation), and also add a note

I worry that a longer explanation will still leave a lot of confusion among beginners, but an extra note is probably an improvement.

... explaining something like "unstable traits are only available on nightly versions of Rust and can either be on track for stabilization or hide implementation details of the standard library". We could use that message anywhere we mention unstable items. We could also open a feature request for something like #[unstable(.., implementation_detail)] to differentiate between perma-unstable and things on track.

The description "only available on nightly" seems like it could be confusing, because you can indirectly use that trait on stable via basic syntax or stable methods. Maybe "unstable traits can only be implemented on nightly" would be better?