Auto-derefencing is too eager

[huonw]

The following seems annoying (and is especially so for writing macros/syntax extensions)

fn main() {
    let x: & int =  &1;

    x.eq(&x); // `x == x` works fine
}

auto-deref.rs:6:9: 6:11 error: mismatched types: expected `&int` but found `&&int` (expected int but found &-ptr)
auto-deref.rs:6     x.eq(&x);
                         ^~
error: aborting due to previous error

[nikomatsakis]

The equivalent of x == y, I believe, is (&x).eq(&y), not x.eq(&y). In any case, I think what is really desired here is another operator for accessing fields/methods that does not do any auto-anything (rather than modifying the auto-deref rules).

[huonw]

@nikomatsakis The type of eq is fn eq(&self, other: &Self) -> bool; which, as much as I understand Rust, means that calling eq is "meant" to be x.eq(&x) (at least it works with let x = 1).

However (&x).eq(&x) does seem get it to work.

[nikomatsakis]

@huonw there is some subtlety here regarding how we select matching trait methods. In this case, you are expecting that we will matchEq with "Self = &int", but what actually happens is that we match Eq with Self = int. Note that the receiver is defined as &self.

That said, something just occurred to me. I think that the problem is not with autoderef per se, but rather with the way that we define the binary operator traits. We ought to define them as follows:

trait Eq {
    fn eq(a: &Self, b: &Self);
}

meaning that x==y would be expanded to:

Eq::eq(&x, &y)

The same would apply to other binary operator traits.

Note that there would be no auto-deref in this case.

[nikomatsakis]

I'm inclined to close this issue. @huonw re-open is you disagree.