stdio line-streaming revisited

[Sean Kelly]

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?

> 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