Passing &dyn Trait from Rc<dyn Trait>

[rnikander]

People seem to think this code should work. But it doesn't.

trait Trait {}
fn foo(_: &dyn Trait) {}
fn bar(rc: std::rc::Rc<dyn Trait>) { foo(&rc) }

The error:

error[E0277]: the trait bound `Rc<(dyn Trait + 'static)>: Trait` is not satisfied
 --> src/main.rs:4:42
  |
4 | fn bar(rc: std::rc::Rc<dyn Trait>) { foo(&rc) }
  |                                          ^^^ the trait `Trait` is not implemented for `Rc<(dyn Trait + 'static)>`
  |

From discussion on discord here.

[fmease]

I'm not sure if the coercion you propose should happen but the user-code fix / workaround would be to explicitly deref: foo(&*rc).

[ais523]

I don't think this is related to Rc. If you use &dyn Trait instead, you get the same error:

trait Trait {}
fn foo(_: &dyn Trait) {}
fn bar(dt: &dyn Trait) { foo(&dt) }

because &dyn Trait doesn't (usually) implement Trait and thus &&dyn Trait can't be coerced into &dyn Trait. If anything, this is an issue with the suggestions in the diagnostics: the version with &dyn Trait (correctly) suggests that you should be using dt rather than &dt (&*dt would also work), but the version with Rc<dyn Trait> doesn't have any suggestions and in particular doesn't tell you that you need to use &*rc to make the types match up.

So the problem here is basically just that there isn't a suggestion to say "you need to reborrow this function/method parameter manually using &*/&**" when you try to use a smart pointer in a situation where a reference was expected. Such a suggestion would probably be very useful; you quite frequently need to add manual reborrows in order to make a program type-check, and yet for people who haven't seen it before, it's non-obvious (and not usually taught very well).

@rustbot label +D-lack-of-suggestion +D-newcomer-roadblock +A-diagnostics

(I also wanted to add an A- label for autoref, which is the relevant part of the language, but we don't seem to have one of those.)

[theemathas]

@ais523 Why doesn't deref coercion kick in though?

[ais523]

@theemathas So there are two potentially relevant mechanisms: autoref/autoderef and the "deref coercion" from &impl Deref<Target=T> to &T. I was thinking primarily about the first at the time of my previous comment.

Despite some some ambiguous wording in the Reference, autoref/autoderef don't apply to function arguments (only to the function that's actually being called), so they don't fix the problem.

Looking into the deref coercion, some experiments show that it doesn't happen at all when the Deref target is dyn Trait (i.e. the coercion target is &dyn Trait). This is apparently undocumented (at least I didn't spot documentation of it in the reference or RFC), but it makes sense to me for coherence reasons: it is possible for &dyn Trait to implement Trait (and this actually happens in practice with traits like Debug and Error), and if both the coercion from &impl Deref<Target=dyn Trait> to &dyn Trait and the coercion from &impl Trait to &dyn Trait were allowed to exist simultaneously, this would create an overlap, allowing code in which either of the two coercions could be used:

fn x(_: &dyn Debug) {}
fn y(d: &dyn Debug) { x(&d); }

The problem there is that you would have to pick one implementation or the other, which might not be the implementation that the programmer wanted (and there's no reason why the implementations would necessarily match). This would at the very least be a semver hazard (adding an implementation of Deref or Trait could cause existing code to be reinterpreted from one coercion to the other), and depending on when the desugaring occurred, might be unsound for the same reason as specialisation.

@rustbot label +A-dyn-trait