On Thu, Jul 23, 2009 at 3:03 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:

David Abrahams skrev:

...

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.

If I remember correctly, he claims that his return of find() is the "correct" one. I think that is plain wrong, as the syntax above shows that there are many useful return ranges, perhaps with an obvious default.

So the above is not an "issue" IMO, but a usable feature.

Yes, that is what I was trying to describe earlier. If we want a parameterisable return range, we need a parameter and an addition to the syntax, Perhaps the assumption that a parameterisable return range is desirable is at fault in which case Andrei's answer is the right one. I agree with Thorsten that the current RangeEx solution is superior because, the parameterisable return is optimally efficient whereas adapters applied to a more general range return type incurs overhead in space and time. I do fully intend to look at Andrei's work in more depth. My previous comment about studying the work briefly was not intended to indicate satisfaction with this state, merely that I am currently ignorant of the full ramifications of the proposed Range Concepts.

-Thorsten

Neil Groves