There's too little value in those ufcsWritef, ufcsWritefln,
ufcsWriteln, ufcsWritefln to justify adding them. When does it stop??
Why not introduce 'std.range.tap', which is more generic and has been
proposed before:
something like this:
T tap(alias fun,T)(T a){
fun(a);
return a;
}
Then:
auto result = data.dostuff.domorestuff.tap!(a=>
writef(fmt,a)).morestuff.finalstep;
of course for non-formatted write it's even simpler:
auto result = data.dostuff.domorestuff.tap!writeln.morestuff.finalstep;
--------
That being said, I believe std.algorithm.reduce DOES deserve it's
counterpart with reversed arguments, more UFCS friendly (which we
could call fold or reduce2), as this is a more common pattern and
std.algorithm.reduce was a design mistake (before ufcs existed).
On Mon, Apr 1, 2013 at 8:20 PM, bearophile <[email protected]> wrote:
> ixid:
>
>
>> UFCS also needs its write function to be able to print whatever data it is
>> passed and then pass exactly the data it was passed on so you can drop write
>> statements into UFCS chains and take them out without needing to chop around
>> the chain.
>
>
> Right, second version:
>
>
> import std.stdio, std.range, std.algorithm;
>
> auto ufcsWrite(T)(T data) {
> write(data);
> return data;
> }
>
> auto ufcsWriteln(T)(T data) {
> writeln(data);
> return data;
> }
>
> auto ufcsWritef(T)(T data, string format) {
> writef(format, data);
> return data;
> }
>
> auto ufcsWritefln(T)(T data, string format) {
> writefln(format, data);
> return data;
>
> }
>
> void main() {
> // Problem from:
> // reddit.com/r/dailyprogrammer_ideas/comments/15in89
> immutable txt = ["Line one", "Line 2"];
>
> txt
> .map!q{ a.length }
> .ufcsWriteln
>
> .reduce!max
> .iota
> .map!(i => txt.transversal(i))
> .ufcsWritefln("%(%s\n%)");
> }
>
>
> Bye,
> bearophile
