Why is std.algorithm so complicated to use?

[Dmitry Olshansky]

On 10-Jul-12 18:15, Jacob Carlborg wrote:
> On 2012-07-10 14:53, Dmitry Olshansky wrote:
>
>> Too bad, as there is no need to make an array when you map something.
>
> How do you store your ranges in a struct or class? Most of them are
> voldemort types.
>

typeof to the rescue. In fact I'm not so proud of voldemort types. As 
when you need to sotre range somewhere they stand in your way for no 
benefit.

>> Then you need something like transform. Anyway the result of map should
>> be sortable it's a bug.
>
> Thank you for clearing that up.
>

>>> The corresponding D version would be:
>>>
>>> auto a = [5, 3, 5, 6, 8].uniq.map!(x => x.to!(string)).array.sort.array;
>
>
>
>> The last array is unnecessary as sort is in-place.
>
> Again, I want an array, not a range.

auto a = [5, 3, 5, 6, 8].uniq.map!(x => x.to!(string)).array;
sort(a);
return a;

Just use the same array, it's just that sort returns a wrapper around 
array (or other range) that indicates it's sorted by predicate x. It can 
then help to reuse this information e.g. to perforam binary search etc.

>
>> Also why would you not sort before map? It'd be faster this way as it's
>> sorting integers.
>
> Isn't it obvious that is just an example and not real code. I'm trying
> to keep the code as short as possible here.
>
Sorry, it wasn't.

>> Thus it's only 2 and one of them is literal. The map can't be sorted
>> because uniq produces lazy bidirectional range. Thus you turn it into
>> array as simple as that.
>>
>> My version would be:
>>
>> auto a = [5, 3, 5, 6, 8].sort().uniq().map!(x => x.to!(string))();
>>
>> fixed?
>
> Still need an array. Real code:
>
> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/IncludeHandler.d#L124
>
>
> I want the end result to be sorted.

Just take an array and call sort on it like in the old days. I don't 
think that stuffing it into one liner is required.
Again if you need an array just call array at the end that's how it's 
supposed to be.

>> Because uniq work only on sorted ranges? Have you tried reading docs?
>> "
>> Iterates unique consecutive elements of the given range (functionality
>> akin to the uniq system utility). Equivalence of elements is assessed by
>> using the predicate pred, by default "a == b". If the given range is
>> bidirectional, uniq also yields a bidirectional range.
>> "
>> Though it doesn't explicitly mentions it, the example is:
>
> Yes, exactly.
>
>> int[] arr = [ 1, 2, 2, 2, 2, 3, 4, 4, 4, 5 ];
>> assert(equal(uniq(arr), [ 1, 2, 3, 4, 5 ][]));
>
> How should I know that from the example?
>
Dunno, to me it says SORTED in one big scary thought. Again it should 
ether check constraint or put some more useful description. e.g.
"(functionality akin to the uniq system utility)" doesn't strike me as 
helpful.

-- 
Dmitry Olshansky