Why is std.algorithm so complicated to use?

[Simen Kjaeraas]

On Tue, 10 Jul 2012 11:41:02 +0200, Jacob Carlborg <doob at me.com> wrote:

> On 2012-07-10 09:09, Jonathan M Davis wrote:
>
>> It's a complete failure because not every range works with every  
>> range-based
>> function? We have isInputRange, isForwardRange, isRandomAccessRange,
>> hasSlicing, etc. for a reason. Different ranges have different  
>> capabilities, and
>> different algorithms generate different types of ranges based on what  
>> they do.
>> For instance, filter cannot possibly have slicing, because it's on O(n)
>> operation to determine which elements match the predicate. You have to  
>> iterate
>> through _all_ of the elements. Rather than doing that (and therefore not
>> working with infinite ranges and being inefficient with non-infinite  
>> ranges), it's
>> lazy, and if you _do_ want to process all of the elements to know  
>> filter's
>> length and therefore make it slicable, you generate a new range from it  
>> -
>> generally with std.array.array. map is in the same boat. It has to  
>> generate
>> new range type, and the choice is between being lazy and efficient (and
>> therefore require a call to array) or being inefficient and calling  
>> array
>> internally.
>
> Well, I haven't been able to use a single function from std.algorithm  
> without adding a lot of calls to "array" or "to!(string)". I think the  
> things I'm trying to do seems trivial and quite common. I'm I overrating  
> std.algorithm or does it not fit my needs?
>

bearophile (who else? :p) has suggested the addition of eager and in-place
versions of some ranges, and I think he has a very good point.

-- 
Simen