Trait object coercion supercedes deref coercion

[abonander]

This seems like it should work: Playground link

use std::sync::Arc;

trait Foo {}

struct Bar;

impl Foo for Bar {}

fn takes_foo(foo: &Foo) {}

fn main() {
    let foo: Arc<Foo> = Arc::new(Bar);
    takes_foo(&foo);
}

However, it seems the compiler is attempting to coerce &Arc<Foo> to a trait object before attempting deref coercion, which gives this unintuitive error:

rustc 1.15.1 (021bd294c 2017-02-08)
error[E0277]: the trait bound `std::sync::Arc<Foo>: Foo` is not satisfied
  --> <anon>:13:15
   |
13 |     takes_foo(&foo);
   |               ^^^^ the trait `Foo` is not implemented for `std::sync::Arc<Foo>`
   |
   = note: required for the cast to the object type `Foo`

Adding a deref-reref seems to fix the issue, but it's definitely a papercut:

takes_foo(&*foo);

[abonander]

@nikomatsakis @nrc Wasn't sure who to ping here, just looking for a judgement on whether this behavior is intended or if it's something that can be improved.

[nikomatsakis]

@abonander hmm yes I agree this is suboptimal. I'm not sure what fix, if any, to do though. For one thing, if we made changes here, it might break code that is using the existing behavior -- and it seems like we'd be trying to make a very narrow targeted change here? (i.e., to detect the case where the trait object would be the same as the result of the deref).

cc @rust-lang/lang

[eddyb]

@nikomatsakis We could try to just reverse the order, I believe both fall through if they fail.

[abonander]

Well the problem that I have isn't that trait object coercion supersedes deref coercion, it's that the compiler doesn't try deref coercion when trait object coercion fails. If we got that working, then it wouldn't break anything, it would just make more code compile that didn't before.

[eddyb]

@abonander It's tricky, because it fails later, and that's required so it doesn't fail if more inference is required, although we could compromise a bit more here? Still, I'm not too happy about more hacks.

[abonander]

Reversing the order I think would introduce subtle breakage because if you have impl Foo for Box<Foo> then it will hit the inner impl first, which is unintuitive.

[nikomatsakis]

Yeah I'm wary of trying to change the order because of breakage.

[HarkonenBade]

I was wondering if any further progress had been made on this? I'm encountering several examples of this defect in code i've been constructing that is using custom smart pointers, and the added derefs are clunky and unhelpful.

[abonander]

I'm still thinking the compiler should attempt both coercions before erroring.

[wpwoodjr]

In addition to the above example, methods can normally be called by passing self as an argument, but not in this case where a trait object would require deref coercion:

trait Foo {
    fn foo_method(&self);
}

struct Bar;

impl Foo for Bar {
    fn foo_method(&self) {}
}

fn main() {
    let foo: &Foo = &Bar{};
    foo.foo_method();                   // OK
    Foo::foo_method(foo);              // OK

    let foo: Box<Foo> = Box::new(Bar);
    foo.foo_method();                   // OK
    Foo::foo_method(&foo);              // Error
}

This seems like an ergonomics consistency issue/bug.
Playground link

[wpwoodjr]

Here's the same issue, this time passing a boxed Bar to a generic parameter which implements Foo:

trait Foo {}
struct Bar;
impl Foo for Bar {}

fn takes_foo_generic<T: Foo>(foo: &T) {}

fn main() {
    let bar = Bar;
    let boxed_bar = Box::new(Bar);

    takes_foo_generic(&bar);         // OK
    takes_foo_generic(&boxed_bar);  // error[E0277]: the trait bound `std::boxed::Box<Bar>: Foo` is not satisfied
}

Playground link

[wpwoodjr]

I think these inconsistencies are confusing, especially for new users, and especially in the example of Box<T> which otherwise acts pretty much like T.