Evaluation order of function arguments

[jkm]

According to TDPL p. 50 (section 2.3.5.3 Function Call) function
arguments are evaluated left to right. This commit fixes the examples in
the documentation where it is assumed that the evaluation order is
unspecified.

I do not know what's the current behavior of dmd regarding function argument evaluation order and whether d-programming-language.org concerns the specification or the current reference implementation. Depending on this you may ignore this request.

[andralex]

Let's leave this on the back burner until the front end actually implements consistent LTR evaluation.

[jkm]

Fine with me. I just wanted to write this to make sure it won't be forgotten.

[alexrp]

What's the state of this?

[jkm]

Not implemented yet as far as I know,

[andralex]

Assigning this to Walter. FWIW Walter and I agree this needs done but Walter didn't have the time. So @9rsr and @dawgfoto you may want to work on this if it catches your fancy, it's a sure hit.

[MartinNowak]

IIRC the biggest difficulty was that cdecl arguments are passed right to left and the front end just used the same evaluation order.
Bugzilla 5749, 6620, 8396

[alexrp]

Let us merge this please. The current state of affairs is that the implementation is wrong, but this documentation is right. @dawgfoto already posted links to the relevant bugs, so I see no reason to not merge this now so other compilers than DMD can implement the defined order.

[andralex]

How would pushing the documentation help the implementation? We've had requests to amend the documentation the other way around.

[alexrp]

The problem is that we're treating the documentation as if it's implementation documentation. It's not. D has no formal specification, so there's no other place to put this kind of stuff. Clearly, LTR evaluation is a language requirement, but since it isn't spec'd anywhere, compiler implementors are not implementing it and it'll remain implementation-defined.

@ibuclaw has said that he'll implement LTR evaluation as soon as it's actually spec'd properly, for instance.

[braddr]

It also changes the LTR ordering from an enhancement request to a compiler bug. It's in some ways semantics (sorry, couldn't resist the pun), but it's also a language design process issue. If we wait for DMD to implement a language change, that bottlenecks language design issues in an odd place.

[dnadlinger]

Imho, there is only one sane option: Document the intended behavior, while at the same time mentioning that it is currently not implemented in DMD (since DMD is our reference frontend, users might be confused if we don't) – the docs are our specs, and how is this ever going to be implemented »correctly« in compilers (excluding DMD) if it isn't even specified behavior?

@dawgfoto: I'd not say extern(C) arguments are passed »right-to-left« – it's DMD which passes arguments in reverse order, if you e.g. compare the extern(D) calling convention to the x86_64 System V ABI description. I don't know the (historic?) reasons for this, but for example in LDC, we are reversing the argument lists for extern(D), not extern(C), functions during LLVM IR generation in order to be compatible to DMD.

By the way, having a language with inline assembly but a totally underspecified calling convention is certainly one of the more annoying thing if you are working on an alternative implementation…

[deadalnix]

@andralex Waiting for DMD to implement things is IMO, one of the reasons D have such a poor tooling. The spec is so tied to DMD that this make the task almost impossible.

BTW, I spend today quite a lot of time today debuging someting like foo() ~ bar; where foo have side effect on bar. It is evaluated in reverse order on linux64.

@klickverbot Exactly. Document intended behavior + mention that the implementation is flawed on the topic.

[ibuclaw]

On 30 September 2012 22:37, David Nadlinger notifications@github.comwrote:

Imho, there is only one sane option: Document the intended behavior, while
at the same time mentioning that it is currently not implemented in DMD
(since DMD is our reference frontend, users might be confused if we don't)
– the docs are our specs, and how is this ever going to be implemented
»correctly« in compilers (excluding DMD) if it isn't even specified
behavior?

@dawgfoto https://github.com/dawgfoto: I'd not say extern(C) arguments
are passed »right-to-left« – it's DMD which passes arguments in reverse
order, if you e.g. compare the extern(D) calling convention to the x86_64
System V ABI description. I don't know the (historic?) reasons for this,
but for example in LDC, we are reversing the argument lists for extern(D),
not extern(C), functions during LLVM IR generation in order to be
compatible to DMD.

Ouchies. But I guess there's more than one way to do it!

While my view is that specificing order of evaluation as something that is
defined may be a big step in the right direction, but it sure leaves a lot
of holes to fill with language implementation issues that arise when LTR is
turned on for function calls.

For instance, how do we deal with code that silently depends on RTL order
of evaluation?https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/arrayop.d#L42

Do we reverse the order of named parameters to bring the desired effect?
(ie: A()[] = B()[] + C()[] => arraySliceSliceAddSliceAssign(b, c, a).
Instead of what currently happens => arraySliceSliceAddSliceAssign(a, c, b)

• however this would require a massive change in the druntime library too
  for the library handed array vector ops).
  Do we modify the frontend to run an analysis on all function parameters and
  create temporaries for all parameters with side effects?
  Should it create a temporary if the callee has side effects too to ensure
  that it gets evaluated before used?

Maybe I'm thinking too hard about it all. :-)

[MartinNowak]

Do we modify the frontend to run an analysis on all function parameters and create temporaries for all parameters with side effects?

Yes, but we're already creating temporaries in some cases.

Should it create a temporary if the callee has side effects too to ensure that it gets evaluated before used?

Not sure if I understand you correctly but if you mean things like get_func()(i++) then we'd have to define whether to evaluate get_func() before or after it's arguments. From the discussion at Bugzilla 5749#c2 it seems that evaluation function calls left recursive makes more sense.

[deadalnix]

It make sens to evaluate everything LTR.

[alexrp]

@andralex Thoughts? At this point, I'd say it's pretty clear that we want LTR evaluation and that the docs should be our spec - most of the compiler developers who have weighed in seem to agree.

@jm Can you alter the pull request slightly so that it mentions that DMD currently does not implement the specified behavior?

[jkm]

I can do that.

[andralex]

Merged, thanks. A page in history has turned. Halfway.