No error despite of multiple applicable methods in scope

[michas2]

Given the following code:

extern crate mio;
use mio::buf::RingBuf;
use mio::buf::Buf;
use std::io::Read;

fn main() {
    let buf = RingBuf::new(10);
    let bytes = buf.bytes();
    println!("{:?}", bytes);
}

buf is of type RingBuf. RingBuf does not provide .bytes(), but it implements both Buf and Read, which both provide a .bytes() implementation.

According to https://doc.rust-lang.org/book/ufcs.html the compiler should complain. But it simply chooses to take the implementation of Read, which return the "wrong" result type.

(Without the "use Read" line rust chooses the implementation of Buf, which return the "correct" type.)

(I am using Rust 1.0.0.)

[bluss]

Edit: Found a good reproduction, I think this explains the situation. I'm still surprised that this is allowed, but the methods in question have different self type -- &self vs self.

struct Type;

trait A {
    fn foo(&self) -> bool { false }
}

trait B : Sized {
    fn foo(self) -> bool { true }
}

impl A for Type { }
impl B for Type { }

fn main() {
    println!("{}", Type.foo());   // This will call B::foo -- it will prefer `self`.
}

[arielb1]

UFCS is not used here (that would be <RingBuf>::bytes). Method lookup tries autoderefs/autorefs in the order 0 autoderef -> 0 autoderef + autoref -> 1 autoderef -> 1 autoderef + autoref -> .... This is required for e.g. rc.clone() (but, of course, not for <Rc>::clone) to work.

We might want to make k autoderefs be ambiguous with k autoderefs + autoref, but this is of course a breaking change (an annotatable one, through) and somebody may be relying on it.

[bluss]

@michas2 It may be that it's a known "feature" of method look up priorities, yours and my example both use the fact that the methods use self vs. &self and thus the self is preferred.

It's confusing but perhaps not a bug like I thought!

As @arielb1 says, using the <Typename>::bytes(...) syntax will produce the ambiguous methods error message.

[alexcrichton]

triage: I-nominated

[pnkfelix]

triage: still an issue.

[steveklabnik]

Triage: still reproduces, not something that I think we're likely to change?

[Spoonbender]

Triage: still reproduces

Do we still consider this a bug?