# Accepting nested method calls with an \`&mut self\` receiver **URL:** \ **Category:** language design\ **Created:** [January 10, 2017, 5:39pm UTC](https://internals.rust-lang.org/t/accepting-nested-method-calls-with-an-mut-self-receiver/4588 "2017-01-10T17:39:07Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\ **Post date:** [January 10, 2017, 6:43pm UTC](https://internals.rust-lang.org/t/accepting-nested-method-calls-with-an-mut-self-receiver/4588/4 "2017-01-10T18:43:48Z")
Broadly speaking, I think my preference would be to autoref and normalize to UFCS form, then apply a consistent evaluation strategy from there. That is, autoref method calls should be semantically equivalent to explicit UFCS, which as little additional magic as possible (autoref already being plenty of magic to worry about). If arguments and borrowing were evaluated right-to-left, then I think your Proposal 1 would fall out naturally from UFCS, no? `vec.push(vec.len())` -\> `Vec::push(&mut vec, Vec::len(&vec))` would take `&vec` and evaluate the length first, then take the `&mut vec` and call `push`. But now I recall past threads where it seems Rust prefers LTR, namely [#28160](https://github.com/rust-lang/rust/issues/28160) and these: > [@Settling execution order for \`=\`, \`+=\`](https://internals.rust-lang.org/t/settling-execution-order-for/4253): > > So I was going through old notifications (ah, the backlog!) and I was reminded that there are some unsettled questions as to Rust execution order that we really ought to get to the bottom of. In particular, Rust generally prefers left-to-right execution order for all expressions – however, we do make some exceptions. Apparently, before MIR, we were actually quite inconsistent here, in that borrowck and trans disagreed on some of the particulars. MIR eliminated that inconsistency, but there are … > [@Rust expression order of evaluation](https://internals.rust-lang.org/t/rust-expression-order-of-evaluation/2605): > > This is my writeup of [issue 28160](https://github.com/rust-lang/rust/issues/28160). Discussion is (and may still be) split between the locations. Currently, the order of evaluation in Rust is undefined, and even inconsistent between borrow-checking an translation (that is unsound, of course). As part of the MIR work, we have an opportunity to define a consistent order of evaluation. The order-of-evaluation of expressions is one of the ugliest corners in imperative language design. To these who have not seen it before, the issue is: in a comp… --- _[View the full topic](https://internals.rust-lang.org/t/accepting-nested-method-calls-with-an-mut-self-receiver/4588)._