Document binary operator argument passing conventions

[brendanzab]

This works:

fn mul<T:Num>(x: &T, y: &T) -> T { *x * *y }

But this doesn't:

fn mul<T:Num>(&x: &T, &y: &T) -> T { x * y }

<anon>:7:23: 7:25 error: cannot move out of dereference of & pointer
<anon>:7          fn mul<T:Num>(&x: &T, &y: &T) -> T { x * y }
                                ^~
<anon>:7:31: 7:33 error: cannot move out of dereference of & pointer
<anon>:7          fn mul<T:Num>(&x: &T, &y: &T) -> T { x * y }
                                        ^~

The above &t: &T pattern could cut down on tons of repetitive derefs within function bodies.

[graydon]

I think this is working as intended. & patterns move out as they are evaluating into the destination if a new binding. * expressions alone (not targeting an assignment) don't. Maybe this requires clarification wrt expression evaluation rules and destination passing style?

[Kimundi]

@graydon: Wait, shouldn't moving out of a & ptr be illegal? You're just borrowing access to the value, moving out of it would mean transfer of ownership.

[huonw]

@Kimundi it's legal for implicitly copyable types, because the move becomes a copy.

[Kimundi]

Well sure, but then there should still be no difference between let x = *y and let &x = y.?

[Aatch]

@Kimundi yes, but that isn't the case here. The expression interacts with autoref/deref and so complicates things.

[nikomatsakis]

This is working as intended. Binary operators implicitly pass their arguments "by reference", so writing _x * *y is equivalent to mul(&_x, &*y), and hence there is no move in the second (working) version. Closing.

[nikomatsakis]

Reopening and repurposing as a bug to improve documentation. I'm not sure whether this is documented or not, but I'd assume not.

[catamorphism]

Nominating.

[pnkfelix]

closing in favor of #10337