stdio line-streaming revisited

[kris]

Sean Kelly wrote:
> Walter Bright wrote:
> 
>> kris wrote:
>>
>>>    Cout.opCall("Hello, ").opCall(Cin.get);
>>
>>
>> Given:
>>     a.f(b,c);
>> can be equivalently written as:
>>     f(a,b,c);
>>
>> we can transform:
>>     Cout.opCall("Hello, ").opCall(Cin.get);
>> into:
>>     opCall(opCall(Cout,"Hello, "), Cin.get);
>>
>> And it is transformed that way, because the optimizer/back end knows 
>> nothing about member functions. They're just more function calls.
> 
> 
> Right.  Out of curiosity, does the ">>" operator have higher precedence 
> than the "<<" operator in C++?  I know I've seen examples there where 
> the operators were mixed on one line, and it seems like they should 
> otherwise work just like the above.
> 
>> It's possible that in the future, to ensure source code portability of 
>> D, that the order of evaluation will become fixed. Such a change is a 
>> fair amount of work to accomplish, and will incur a runtime penalty 
>> (the implementation defined order allows the compiler to rearrange 
>> things to minimize register pressure). Even if the order was fixed, it 
>> still might not be in the right order for call chaining to work as 
>> your design needs it to.
> 
> 
> I'm still undecided whether this would be a good thing.  It's more 
> predictable, certainly, but it isn't clear whether that predictability 
> is worth the loss of efficiency.  I don't suppose the compiler could 
> somehow detect situations where such dependencies exist and only prevent 
> optimizations for those?

FWIW: I don't believe that it is necessary to cement order of eval for 
arguments in the general case. There are undoubtedly good reasons for 
the variety of "call protocols" (argument passing), and fixing the order 
of eval would certainly have an effect upon their efficiency. As long as 
call-chaining is supported in the intuitive manner that it currently is, 
I would say the rest of the concerns are probably "implementation dependent"

2c

> 
>> I also suggest that, with the maturing of the variadic template 
>> capability of D, using it will side step the order of evaluation 
>> problem completely. It'll still be an aesthetically pleasing design to 
>> the user.
> 
> 
> Certainly.  About the only thing we'll need to resolve is that Stdout( 
> "a", "b" ) currently prints "a, b" (ie. the default formatter output is 
> comma delimited), and the lack of consistency here would be confusing.
> 
> 
> Sean