SortedRange and new docs for std.container

Tomek Sowiński just at ask.me
Wed Sep 8 13:52:26 PDT 2010


Dnia 08-09-2010 o 15:55:30 Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> napisał(a):

> I just added SortedRange as discussed a while ago in this newsgroup. I  
> think it turned out pretty neat. Generally the range abstraction is  
> turning out to be very solid.
>
> To get a SortedRange object for a given range r either call sort(r) if  
> you want to sort one, or assumeSorted(r) if you know that the range is  
> sorted already.

1. I'm missing quantile, though it's trivial to compute.
2. Could makeIndex() also return SortedRange? The predicate should be  
morphed of course to account for dereferencing.
3. Overall impression is good.

> I've also fixed Zip (finally!) to get rid of a couple of dirty tricks.  
> It turns out that front()/front(v)/moveFront() are a correct way to  
> abstract proxy ranges like Zip is.

Good to hear. Speaking of Zip, I often find myself assembling combos like  
map!fun(zip(r1, r2, ...). Nothing wrong with it, but there's usually a  
problem with the transformation function -- I always have to make my own.  
If I have a function that takes multiple parameters (can happen), I can't  
plug it directly, I have to make a wrapper that takes a tuple and forwards  
fields to the arguments. So how about zip!funnel(r1, r2, ...)? funnel must  
take the sequence of ElementTypes of the zipped ranges as parameters. The  
ElementType of the resulting range is funnel's return type. Plus, the  
compiler is not bothered with optimizing out the intermediary tuple of  
arguments.

Would the ROI of this feature be positive?


Tomek


More information about the Digitalmars-d mailing list