stdio line-streaming revisited

[Frits van Bommel]

jcc7 wrote:
> == Quote from kris (foo at bar.com)'s article
>> jcc7 wrote:
>>> == Quote from kris (foo at bar.com)'s article
>>>
>>>> Frits van Bommel wrote:
>>>> [snip]
>>>>
>>>>> What I'm trying to say here is basically this: you shouldn't rely on the
>>>>> order of evaluation of parameters. Not even if one of them happens to be
>>>>> used as 'this' for the method in question.
>>>> Absolutely agree. Yet, without wishing to go off on a tangent, we're
>>>> talking about call-chaining and not parameter evaluation-order. These

Actually, we *were* talking about parameter evaluation-order in this 
subthread. From the post I was replying to:
---
We discussed this a long time ago and came to the conclusion that while 
the D spec does not guarantee *evaluation order* for this scenario, it 
seems impossible for it to be anything other than left to right because 
the chained calls rely on the return value from previous calls
---
(emphasis added)

>>>> are different things, and there was a painfully long thread on exactly
>>>> this subject a year or two ago.
>>>> Walter closed that one by stating call-chaining can only realistically
>>>> evaluate from left to right (or something to that effect) and that's
>>>> what D does.
[snip]

Yes, call-chaining can only evaluate left-to-right, but the parameters 
*passed* to the calls can be evaluated in any order.

> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=31264

(Assuming that's the correct thread)

The closest thing to "Walter closed that one by stating call-chaining 
can only realistically evaluate from left to right" I can find is this 
post[1]:
---
Walter Bright Wrote:
 > "Manfred Nowak" <svv1999 at hotmail.com> wrote in message
 > news:Xns9727D45B325B1svv1999hotmailcom at 63.105.9.61...
 > > Moreover the behaviour of the whisper notation is undefined according
 > > to the specs, which clearly state that the order of all expression
 > > evaluations are undefined if not explicitely defined---and no
 > > definition for the whisper notation is given.
 >
 > I've been intending for a while now to revise that to make the order of
 > evaluation explicit. The undefined order of evaluation does not offer 
many
 > benefits, and causes a lot of headaches.
 >
 > But there are two different things here: order of evaluation, and 
operator
 > precedence. D operator precedence is clearly defined. For example:
 >
 >     a + b + c
 >
 > is defined to be:
 >
 >     (a + b) + c
 >
 > There is no ambiguity. The order of evaluation ambiguity comes from the
 > order a, b, and c are evaluated. For example, for:
 >
 > void a() { writefln("a"); }
 > void b() { writefln("b"); }
 > void c() { writefln("c"); }
 > ...
 > a() + b() + c()
 >
 > may output one of:
 >
 > abc
 > acb
 > bac
 > bca
 > cab
 > cba
---

All he said was that the translation from expression to explicit opAdd 
calls is fixed by operator precedence, and that he was thinking about 
defining order of evaluation for the parameters in an expression. 
However, nowhere did I see *how* he intended to define it, nor that he 
ever did so.


[1]: 
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=31263