Two easy pieces

Timothee Cour thelastmammoth at gmail.com
Mon Apr 1 21:52:00 PDT 2013


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 <bearophileHUGS at lycos.com> 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


More information about the Digitalmars-d-learn mailing list