Why is std.algorithm so complicated to use?

[Dmitry Olshansky]

On 10-Jul-12 17:56, Jacob Carlborg wrote:
> On 2012-07-10 15:28, Andrei Alexandrescu wrote:
>
>> We can arrange things in the library that a custom message is issued, or
>> in the compiler to do it once for all. At any rate whenever there's an
>> error pointing somewhere in the library's code that's an insufficient
>> template constraint that should be fixed.
>
> I mean, is it possible to have the original code work?
>
> auto bar = foo.chain("bar");
>
> Or perhaps more appropriate:
>
> auto bar = foo.append("bar");
>
>
>> Well I made minimal changes. Besides I don't know what the intent is.
>
> Have a look at this:
>
> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L217
>
>

I'm not sure how map can fit there. If anything you need a foreach (and 
you have it;) ) to build a _string_. I'd rather output ',' right there 
inside of loop. Thus avoiding costly join and appending to a new buffer 
on each iteration.

Other then doing it with Appender and generalizing to any OutputRange I 
fail to see a problem.

> I was going to replace the foreach-loop in the above code with a call to
> "map". But "map" returns a range, not an array. Therefor the append at
> line 245 won't work. How would I do line 245 if "params" is a range
> returned by "map"?
>
> It seems unnecessary to have to convert the range to an array before
> "join" is called on line 247.
>
>> Indeed I agree there should be no error in library code. What I meant to
>> say was, when I saw the code I thought "I bet this is an lvalue thing",
>> and then when I saw lvalue in the error I was satisfied.
>
> Jonathan has already reported these two bugs.
>
>> I understand. So you need to use array() to convert the lazy map result
>> into an eager array. I disagree this is unintuitive, if it were then
>> very little of D would make sense are lazy, non-array ranges are
>> everywhere.
>
> Tell me what is the point of std.algorithm and ranges if I have to
> convert every single result of an algorithm to an array before I can use
> it with an other algorithm? I thought the whole idea was to avoid
> allocations between different usages of algorithms.
>
Speed and generality. Think removing temporary arrays. And while a lot 
of folks won't every use things other then arrays power users sure as 
hell would.

-- 
Dmitry Olshansky