On 2013-11-14, at 5:54, Huon Wilson <[email protected]> wrote: > On 14/11/13 14:50, Tommi wrote: >> let mut n = 11; >> let p: &int = &123; >> >> p + n; // OK >> n + p; // error: mismatched types: expected `int` but found `&int` >> >> Shouldn't this error be considered a compiler-bug? The Add trait says '&' >> for rhs after all: >> fn add(&self, rhs: &RHS) -> Result; >> >> -Tommi >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev > > This is https://github.com/mozilla/rust/issues/8895 . I believe it is caused > by the implementation details of the overloaded-operator desugaring (a + b is > equivalent to `a.add(&b)`, so auto-deref allows for `a: &T` with `b: T`), I > personally think the more sensible resolution would be for `p + n` to be > disallowed as well as `n + p`. > > Huon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
Thanks, I tried to search for a bug report for this but didn't manage to find that one. To me it makes perfect sense that p + n would work because if a + b is specified to be "just" syntactic sugar for a.add(b), then a + b should behave exactly like a.add(b), with implicit pointer dereferencing and all that good stuff. But, I don't understand why is it a.add(&b) like you said, though. By the way, I would hate all of this behavior if Rust had pointer arithmetic, but luckily it doesn't seem to have it. -Tommi _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
