Document function argument evaluation order (or lack thereof)

[moxian]

A question I stumbled upon today, and couldn't find the answer in the reference.

Consider the following program:

struct Counter {
    v : i32
}
impl Counter {
    fn next(&mut self) -> i32 {
        self.v += 1;
        self.v
    }
}

fn show(first: i32, second: i32) {
    println!("{} {}", first, second);
}

fn main(){
    let mut x = Counter{v: 0};
    show(x.next(), x.next());
}

In my experience it always prints 1 2 but I want to know whether this is guaranteed, or if it is (like, e.g., in C++) explicitly undefined.
The most obvious place to put the answer is https://doc.rust-lang.org/reference/expressions/call-expr.html (or just https://doc.rust-lang.org/reference/expressions.html)

Same question for order of evaluation of tuple elements.

[Havvy]

I was told, but without a source of truth, that the order of evaluation of expressions is the order they are written in at the call site. So for function arguments and tuples they will always be left to right. For struct expressions, it's the order in which the field names are written.

[alercah]

I believe that's correct, but there's a caveat around the callee of a function expression and the receiver of the method, I think. I don't recall the behaviour off the top of my head; easy enough to double-check. We should probably document two-phase borrow at the same time, for receiver expressions.

…

On Thu, 24 May 2018 at 04:12 Ryan Scheel ***@***.***> wrote: I was told, but without a source of truth, that the order of evaluation of expressions is the order they are written in at the call site. So for function arguments and tuples they will always be left to right. For struct expressions, it's the order in which the field names are written. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#332 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT4HVXJali5v1MYBuBzrHX2hOcrle7Ahks5t1mt6gaJpZM4T7Q4T> .

[ehuss]

@Havvy Does #888 resolve this?

[Havvy]

Yes.