Explicitly define the evaluation order/"sequence points" etc.

[huonw]

From this stackoverflow question.

I may just not be searching for the right terms, but I don't believe this is mentioned in the manual. It would be good to have this clearly defined.

There is possibly some subtlety with issues like #6268, where it may make sense to evaluate the receiver last.

[huonw]

@chris-morgan's investigation on that SO question turned up this:

fn foo(_: (), x: int) -> int {
    x
}

fn main() {
    let mut a = 1;
    {
        a * foo(a = 3, a)
    };
}

The block evaluates to 9, while I was expecting 3 with a ltr evaluation order.

[chris-morgan]

For reference, some playing around with things: http://is.gd/ynMTY7

trait Actually {
    fn actually<U: ::std::fmt::Show>(self, U) -> U;
}

impl<T: ::std::fmt::Show> Actually for T {
    fn actually<U: ::std::fmt::Show>(self, u: U) -> U {
        println!("{} actually {}", self, u);
        u
    }
}

fn main() {
    let mut a;
    // -13, 5, -13, 5, -23, 5, -23, 5, -8, 5.
    println!("{}", {a = 2i; a} - {a = 3; a} * {a = 5; a});
    println!("{}", a);
    println!("{}", (a = 2i).actually(a) - (a = 3).actually(a) * (a = 5).actually(a));
    println!("{}", a);
    println!("{}", {a = 2i; a} - a * {a = 5; a});
    println!("{}", a);
    println!("{}", (a = 2i).actually(a) - a * (a = 5).actually(a));
    println!("{}", a);
    println!("{}", (a = 2i).actually(a) - ().actually(a) * (a = 5).actually(a));
    println!("{}", a);

    let mut a;
    // These ones always end up as `false`
    println!("{}", {a = true; a} && {a = false; a});
    println!("{}", a);
    println!("{}", {a = false; a} && {a = true; a});
    println!("{}", a);
    println!("{}", (a = true).actually(a) && (a = false).actually(a));
    println!("{}", a);
    println!("{}", (a = false).actually(a) && (a = true).actually(a));
    println!("{}", a);

    // These ones always end up as `true`
    println!("{}", {a = true; a} || {a = false; a});
    println!("{}", a);
    println!("{}", {a = false; a} || {a = true; a});
    println!("{}", a);
    println!("{}", (a = true).actually(a) || (a = false).actually(a));
    println!("{}", a);
    println!("{}", (a = false).actually(a) || (a = true).actually(a));
    println!("{}", a);
}

[huonw]

Ok, to expand on my comment above (inspired by the last two expressions in the numeric part of @chris-morgan's example), these two differ in evaluation order, even though the only difference is the introduction of the noop foo((), ...) around the a on the LHS:

fn foo(_: (), x: int) -> int { x }

fn main() {
    let mut a = 2i;
    println!("{}", a * foo(a = 5, a)); // 25
    a = 2i;
    println!("{}", foo((), a) * foo(a = 5, a)); // 10
}

http://is.gd/zVdDoh

Nominating.

[pnkfelix]

cc me

[petrochenkov]

While experimenting with evaluation order I (author of SO question) noticed some strange interaction with borrow checker. Consider the next code:

fn my_add(lhs : &int, rhs : &int) -> int { *lhs + *rhs }; // the same as built-in add

let mut a = 1i;
let b1 = my_add({a = 10; &mut a}, {a = 100; &mut a}); // custom add, does't compile, borrow checker is not pleased
let b2 = *{a = 10; &mut a} + *{a = 100; &mut a}; // built-in add, suspiciously compiles, modifying and borrowing "a" while already borrowed

But built-in add is supposed to behave as if it was a function call to the corresponding method of Add trait, right?

[pnkfelix]

@petrochenkov I suspect the reason for the discrepancy you are observing is two-fold.

First, I do not think you are 100% correctly translating the infix-+ to a direct call to the function, at least in terms of how the compiler internally sees it. I think the correct translation probably looks more like this:

    let b3 = {
        let tmp1 = *{a = 10; &mut a};
        let tmp2 = *{a = 100; &mut a};
        my_add(&tmp1, &tmp2)
    };

(Or at least, the above does correspond to to the *{a = 10; &mut a} + *{a = 100; &mut a} in my head, and it successfully compiles in rustc.)

Note in particular that I am dereferencing the &mut a and then reborrowing it immutably in the bindings of tmp1 and tmp2; this is because I have just taken the input expressions you fed into your infix-add (which had derefence operations) and then explicitly added the borrows that the infix-add will put on itself when converting to the calls to the fn add method.

---

Second, one might think, "okay, if what Felix said above works, then why didn't he write the desugaring this way:"

    let b4 = my_add(&*{a = 10; &mut a}, &*{a = 100; &mut a});

And indeed, I did sidestep that possible desugaring. Or rather, I did that one first, myself, but it did not compile. That might be related to the problem documented in #6268. (Or it might not be; I thought it was at first, but on further examination I am not sure if it is or should be.)

[petrochenkov]

I think the correct translation probably looks more like this:
let b3 = {
let tmp1 = *{a = 10; &mut a};
let tmp2 = *{a = 100; &mut a};
my_add(&tmp1, &tmp2)
};

Aha, it means that built-in add does "lvalue to rvalue conversion" (in C++ terms), then borrow checker is correct. But in this case built-in add doesn't implement Add trait, but something slightly different:
fn add<int, int>(self, rhs: int) -> int; // arguments by value
i.e. the same distinction between built-in and overloaded operators as in C++ takes place. Correct?

[pnkfelix]

@petrochenkov no, the infix-+ operator definitely implements the Add trait as specified. (There is an on-going discussion about changing the definition of Add so that it takes its inputs by value instead of by reference, but that is not the current state of things.)

The difference is that the infix-+ operator automatically adds the & to the inputs that you feed it, which is part of what I was trying to show you in my desugaring: note that I added & to each of the two input arguments when I passed them as tmp1 and tmp2.

[pnkfelix]

@petrochenkov Let me put this a different way: Whatever you do to translate <A> + <B> to my_add(<C>, <D>), the expression <A> should appear directly within <C>, and likewise <B> should appear directly within <D>.

But in your in your original comparison, you had something that looked like:

let b1 = my_add(E1, E2);
let b2 = *E1 + *E2;

Note that *E1 (the <A>) does not appear within E1 (the <C>), and likewise *E2 does not appear within E2.

This is why I re-wrote your example instead as something similar to:

let b3 = my_add(&*E1, &*E2);

so that now the *E1 does appear directly within &*E1. And likewise *E2 within &*E2.

This may seem like a minor detail, but the difference between { &mut foo } and &*{ &mut foo } is quite significant.

[petrochenkov]

@pnkfelix

the difference between { &mut foo } and &*{ &mut foo } is quite significant.

I understand - the mutability is different. But I'm still not convinced :)
I'll try to follow the abstract evaluation step by step as I understand it. My assumptions are:

• all the evaluations are sequenced, including built-in operations
• int behaves as if it implemented Add trait exactly

1. my_add({a = 10; &mut a}, {a = 100; &mut a});
   a) the expression {a = 10; &mut a} (first argument) is evaluated, the result has type &mut int (let's cal it b)
   b) b is implicitly converted to &int (c), because my_add has &int as a first parameter
   c) c is saved to be later passed to my_add, i.e. a is borrowed as immutable now
   d) we can't evaluate {a = 100; &mut a}, because a is borrowed as immutable

2. *{a = 10; &mut a} + *{a = 100; &mut a}
   a) the expression *{a = 10; &mut a} is evaluated, the result is a mutable lvalue of type int (b)
   b) operator + under the cover apply operator & to b, the result is of type &int (c)
   c) c is already has type &int as required by Add::add, so no implicit conversion happens
   d) c is saved to be later passed to Add::add, i.e. a is borrowed as immutable now
   e) we can't evaluate {a = 100; &mut a}, because a is borrowed as immutable... wait, we can!?

[pnkfelix]

We are not going to attempt to do this exercise of formally defining the evaluation order for 1.0. Therefore, not assigning this to the 1.0 milestone.

Specific suprises that are currently exhibited by the rustc compiler should be filed as their own bugs.

[pnkfelix]

Having said the above ...

Having the evaluation order actually written up and specified is something that someone should do eventually. Therefore, we will keep this bug open.

Tagging as P-low, (not 1.0 milestone).