another round of call-chaining mystery?

[kris]

James Dennett wrote:
> kris wrote:
> 
>>James Dennett wrote:
>>
>>>kris wrote:
>>
>>[snip]
>>
>>>>There never was any argument of which you claim. I simply noted that
>>>>eval-order had been clarified before, using your usage of "eval-order"
>>>>from within the same post. If you revisit, you'll see that was actually
>>>>referring to call-chaining instead, so there's perhaps a misuse of
>>>>terms:
>>>>
>>>>  Cout.opCall("Hello, ").opCall(Cin.get);
>>>>
>>>>As you can see, there is only one parameter passed to each call, and
>>>>therefore the order of /parameter/ eval is "not at stake here" (as I
>>>>noted to Frits). 
>>>
>>>
>>>There are two arguments to the second opCall.  One is
>>>the result of Cout.opCall("Hello, ") and the other is
>>>the result of Cin.get, and they can be evaluated in
>>>either order unless some rule prohibits it.
>>
>>I think you'll find that call-chaining does not operate in that manner,
>>James? If you look a bit closer, you'll see that the lhs has to be
>>evaluated first, simply to get something to deref the rhs. Further,
>>there is only one argument permitted to the opCall() itself
>>
>>For a fuller description, I suggest you bring it up with Walter instead?
> 
> 
> Walter's post in this thread (<eui80b$19hl$1 at digitalmars.com>)
> seems to confirm my viewpoint as quoted above.  If you still
> don't think so after reading his message, I'd be interested
> if you can explain where Walter's explanation differs from
> mine.
> 
> Regards,
> 
> James.

Simply because that's what Walter led us to believe a long time ago, 
James, and it is how the compiler is implemented. Don't know what else 
to tell you.