Identify which tuple item fails to implement a trait when using fake variadics

[alice-i-cecile]

Code

trait WorksOnDefault {
    fn do_something() {}
}

impl<T: Default> WorksOnDefault for T {}

fn main() {
    let _success = <(i32, u32, String)>::do_something();
    let _failure = <(i32, &u32, String)>::do_something();
}

Current output

error[E0599]: the function or associated item `do_something` exists for tuple `(i32, &u32, String)`, but its trait bounds were not satisfied
  --> examples/hello_world.rs:11:28
   |
11 |     <(i32, &u32, String)>::do_something();
   |                            ^^^^^^^^^^^^ function or associated item cannot be called on `(i32, &u32, String)` due to unsatisfied trait bounds
   |
note: the following trait bounds were not satisfied:
      `&(i32, &u32, String): Default`
      `&mut (i32, &u32, String): Default`
      `(i32, &u32, String): Default`

Desired output

No method `works_on_default` found for <(i32, &u32, String)>`

The method `do_something` is available via the `WorksOnDefault` trait for any type T where T implements the `Default` trait.

If every member of the tuple (i32, &u32, String) implemented the `Default` trait, the `Default` trait would be implemented for the tuple.

However, `&u32` does not implement the `Default` trait.

note: did you mean `u32`, which implements the `Default` trait?

Rationale and extra context

This is an extremely common pattern for Bevy, primarily in our system and bundle code patterns. The poor error messages are one of our largest UX / teaching problems,. See #89681 for that specific issue, which could be fixed by more general improvements here.

This pattern occurs all over the place: the minimal example here uses Default, which relies on the same flavor of fake variadics for tuples where all tuple elements implement a given trait. Bevy's Bundle tuples matches this form exactly, while our Systems use the same sort of trick but with functions, where each parameter must implement SystemParam.

Other cases

fn main(){
    let _successful_default = <(i32, u32, String)>::default();
    let _failed_default = <(i32, &u32, String)>::default();
}

The error output when calling methods from the trait directly correctly identifies the problematic variant:

error[E0599]: the function or associated item `default` exists for tuple `(i32, &u32, String)`, but its trait bounds were not satisfied
 --> src/main.rs:3:50
  |
3 |     let _failed_default = <(i32, &u32, String)>::default();
  |                                                  ^^^^^^^ function or associated item cannot be called on `(i32, &u32, String)` due to unsatisfied trait bounds
  |
  = note: the following trait bounds were not satisfied:
          `&u32: Default`
          which is required by `(i32, &u32, String): Default`
``

Rust Version

rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0
LLVM version: 20.1.1

Anything else?

Discussed with @estebank and @joshtriplett at RustWeek 2025, where I was encouraged to file an issue so we can improve diagnostics without waiting on full variadics!

[joshtriplett]

👍 for attempting to detect and diagnose this case, when looking for a trait impl for a tuple.

[estebank]

Any thoughts on this output?

text version

error[E0599]: the function or associated item `do_something` exists for tuple `(i32, &u32, String)`, but its trait bounds were not satisfied
   --> traits-on-tuples.rs:24:43
    |
24  |     let _failure = <(i32, &u32, String)>::do_something(); //~ ERROR E0599
    |                                           ^^^^^^^^^^^^ function or associated item cannot be called on `(i32, &u32, String)` due to unsatisfied trait bounds
    |
note: the following trait bounds were not satisfied:
      `&(i32, &u32, String): Default`
      `&mut (i32, &u32, String): Default`
      `(i32, &u32, String): Default`
   --> traits-on-tuples.rs:5:9
    |
5   | impl<T: Default> WorksOnDefault for T {}
    |         ^^^^^^^  --------------     -
    |         |
    |         unsatisfied trait bound introduced here
note: `Default` is implemented for `(i32, u32, String)` but not for `(i32, &u32, String)`
   --> /home/gh-estebank/rust/library/core/src/tuple.rs:242:1
    |
242 | tuple_impls!(E D C B A Z Y X W V U T);
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: this error originates in the macro `tuple_impls` (in Nightly builds, run with -Z macro-backtrace for more info)

As a bonus, it works on things other than (...): Default:

The logic right now just retries with a tuple without any borrows, but the logic could be made more complex to try different combinations ("check every combination of removing borrows from every type and adding borrows"), but I'd like to leave that as a follow up.

[alice-i-cecile]

I quite like the output! Agreed on leaving more complex retry logic for later: the key thing here is showcasing which element didn't meet the trait bounds.

[weiznich]

This looks great.

Nevertheless I would like to raise a few points to prevent future problems. @estebank Mentions that the logic could in the future retry with different combinations. While that would be really useful, it is likely also very important to be carefully with which combinations should be retried. For example diesel has this 128-columns-table feature, which implements a number of traits for tuples with up to 128 elements. If you retry with all possible combinations for such a tuple you will certainly run into performance problems just due to the combinatorical complexity due to the number of elements. So maybe there should be a hard limit for how many variants the compiler tries before giving up.

The other thing I want to mention in this context is yet another idea that might help to improve error messages around such tuple impls significantly. At least in diesel (and I assume in bevy) as well there are often trait impls like impl Queryable<(Some, Tuple, Of, Types), Whatever> for (Other, Tuple, Of, Types) which are essentially only implemented if both tuples match in size (+ Each of the tuple elements implement an trait based on each other). It happens from time to time that a user manages to skew up the size of one tuple for whatever reason so that they have different sizes. For such cases it would be really helpful to just point out: This trait is only implemented if the tuple sizes match, but you got x elements there an y elements there. If that's helpful I can try to provide a minimal example for such an error case.

[estebank]

@weiznich very important points. Yes, we should have a limit on how many things we try. I think an example of the second case would be useful and should be handled separately.

[weiznich]

I've put together a minimal example for the second case here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=6cc46789f0f7bd40298c7ca91f91575a