Ambiguous method call - should this error?

[mitchmindtree]

Hey folks,

I had a contributor track down a bug that slipped through in one of my crates. It took them a few hours, and turned out to be caused by an ambiguity in next method calls. Here's the example of the bug that they gave:

pub trait Window {}

pub struct PistonWindow {}
impl Window for PistonWindow {}


struct WindowEvents {}
impl WindowEvents {
    fn next<W: Window>(self, arg: &W) {
        println!("WindowEvents::next");
    }
}

trait EventWindow {
    fn next(self, arg: &PistonWindow);
}
impl EventWindow for WindowEvents {
    fn next(self, arg: &PistonWindow) {
        println!("EventWindow::next");
    }
}

fn main() {
    let struct1 = PistonWindow {};
    let struct2 = WindowEvents {};
    
    struct2.next(&struct1);
}

playpen

Here, I would normally assume rustc to throw an error about an ambiguity between the next method call, something like:

multiple possible sources of next method:
1. inherent method `WindowEvents::next`
2. trait method `EventWindow::next`

Instead, the program compiles and the WindowEvents inherent method is called.

Perhaps this is expected behaviour and I'm missing something, but just thought I'd report in case.

[nagisa]

Seems like intended behaviour to prefer inherent methods, as something as simple as this works:

struct A;
trait B { fn next(&self) { println!("trait"); } }

impl B for A {}
impl A {
    fn next(&self) { println!("inherent"); }
}

fn main() {
    let a = A;
    a.next()
}

---

Consider this:

struct2.next(&struct1); is sugar for typeof(struct2)::next(struct2, &struct1) (i.e. WindowEvents::next(struct2, &struct1)). This is then resolved as per rules described in UFCS RFC:

As per

Whenever a path like ...::a::... resolves to a type (but not a trait), it is rewritten (internally) to <...::a>::....

you get <WindowEvents>::next(struct2, &struct1).

As per

Given a path <T>::m::...:

1. Search for members of inherent impls defined on T (if any) with the name m. If any are found, the path resolves to that item.

---

I’m personally kind of surprised that the compiler doesn’t even warn about possibility of ambiguousity, but by now the best you can hope for is a allow-by-default lint, possibly in clippy.

[Mark-Simulacrum]

I am fairly certain that inherent methods are intended to be preferred, closing.