Re: [boost] [Range] initial feedback on return values of algorithms

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-03 07:59:32

Thorsten Ottosen <tottosen_at_[hidden]> writes:

> Eric Niebler wrote:
>> Thorsten Ottosen wrote:
>> 
>>>Dear all,
>>>
>>>The plan is to include range-based overloads of std algorithms in the 
>>>next boost.range.
>> 
>> 
>> 
>> Range algorithms are more complicated than they look. I think it would 
>> be a mistake to bang this out and sneak it in without a full review.
>
> ok, I was hoping for a mani-review, but I don't mind a full review.
>
>>>We have several options for specifying the return type
>>>of functions that normally return an iterator that I would like your 
>>>feedback on.
>> 
>> 
>> 
>> This is, of course, just one of the questions range-based algorithms 
>> raise, and probably the least controversial.
>
> the others would be
>
> a. calling members
>
> b ?
>
>
>>>1. leave the return type as it is.
>> 
>> 
>> 
>> Not a good idea. Range algorithms should consume *and* produce ranges. 
>> This is so that multiple range algorithms can be composed/chained 
>> together, a-la the functional style of programming.
>
> right, but do you also waht sort() to return the sorted range?

Yes, but as a "reference" to the original, i.e.  a boost::range
iterator bundle.

>> There are lots more issues with range algorithms that have not been 
>> discussed yet. What about algorithms that accept an output iterator and 
>> write into it? Will they now take an output range? 
>
> My say would be no. We still have the concept of an unbounded iterator.

There is also the issue of O(1) size, for which you have not got
support in your concept hierarchy.  And then there's property maps.

> The unsafe usage of copy should be done with a new function called
> overwrite(rng1,rng2) which can tjeck the bounds with an assert.

That might make sense.

>> ? Is it undefined behavior? Or is this range-checked? And if so, do we 
>> truncate, assert or throw? Is there a way to make range-checking 
>> optional? Can we specify the failure mode? And what should the default be?
>
> Using an exception seems not to in the spirit of STL.

Not that I like it, but there's vector<T>::at.

>> And what does br::copy return? You might think the answer is easy: the 
>> range designating the unused elements at the end of the second range. 
>> But what if br::copy is range-checked and truncates? That return value 
>> is no longer sufficient -- if br::copy returns an empty range, did the 
>> algorithm truncate, or did it all just fit?
>
> I'd be quite happy with copy returning void.

I think that's a mistake.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com