David Abrahams wrote:
Hi Neil,
I'm sure someone already spoke to you about this, but just in case: Andrei Alexandrescu gave a very interesting presentation at BoostCon that was based on a "ranges only" approach that should eliminate issues like this one:
2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.)
boost::find[_f,_e]( range, x )
boost::find[_f+1,_e]( range, x )
He says he's implemented a superset of the STL algorithms with it so we know the expressive power is fairly complete. I was wondering if you had given any thought to making use of his insights? Especially considering that RangeEx hasn't been used to fully cover a generic domain (I think), it might make sense.
First-class ranges would still need to be convertible to iterator pairs, since iterators are useful on their own as a mean to express positions. For example, let's say I write a simple algorithm that takes three bidirectional iterators: the begin of the sequence, the end of the sequence, and a position anywhere in between. That algorithm then returns whether the position in between lies on a word boundary by reading what is left and right of it. How would I express such an algorithm with ranges only? If we agree that we need iterators anyway, first class ranges would be nothing more than an optimized version of iterator pairs that can only be applied in certain cases; so dealing with iterator pairs as ranges remains needed (and not only for legacy purposes).