On 25/11/15 15:47, Michael Matz wrote: > Hi, > > On Tue, 24 Nov 2015, Richard Biener wrote: > >> On Tue, Nov 24, 2015 at 12:01 AM, Jason Merrill <ja...@redhat.com> wrote: >>> There's a proposal working through the C++ committee to define the order of >>> evaluation of subexpressions that previously had unspecified ordering: >>> >>> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf >>> >>> I agree with much of this, but was concerned about the proposal to define >>> order of evaluation of function arguments as left-to-right, since GCC does >>> right-to-left on PUSH_ARGS_REVERSED targets, including x86_64. > > Actually the most natural order for an (normal, stack-passing) > implementation that supports varargs is right-to-left, so the proposal has > it exactly backwards. (Reason being that named arguments then have > constant offsets from stack pointer). > > right-to-left is also the better order for all ABIs that pass (at least > some) arguments on stack but give left arguments smaller offsets from > top-of-stack (as most ABIs do). >
That is all true - but if you have to pick an order that makes sense to users, especially of functions that are not varargs (i.e., most functions), then left-to-right is the only logical, natural order - at least for those of use who use left-to-right languages. How often would left-to-right evaluation actually cause efficiency problems? It would only be for functions that take a lot of parameters or a variable number of parameters, and then only when calling them with arguments that are calculated in a way that might have side-effects (otherwise the compiler is free to re-order them anyway). Is that really going to be a big issue? One should not limit the language just because of a tiny efficiency issue with rarely-used cases. (The other orderings discussed in the proposal seem fair enough - it is only function parameter ordering that is an issue, I think.)
