Re: [boost] [range] How to extend Boost.Range?

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-15 09:35:30

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> David Abrahams <dave <at> boost-consulting.com> writes:
>
>> 
>> Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:
>> 
>
>> > then what about the following:
>> >
>> > Returns:
>> >  
>> >   x.first         if x is an std::pair
>> >   x               if x is an array
>> >   range_begin(x)  if range_begin() can be found by ADL
>> >   x.begin()       otherwise
>> >
>> > ?
>> 
>> that would be an improvement.  I think you need "otherwise," at the
>> beginning of all lines of the 2nd column but the first. 
>
> like so
>
> x.first         if x is an std::pair, otherwise
> x               if x is an array, otherwise
> range_begin(x)  if range_begin() can be found by ADL, otherwise
> x.begin()       
>  
> ?
>
> I personally think having one "otherwise" is ok. lot's of math do it like that.

I think I changed my mind.  I agree with you.

>> Nitpicking,
>> 
>>    range_begin(x)  if range_begin() can be found by ADL
>> 
>> is not quite right.  I think it's more like
>> 
>>    range_begin(x) if range_begin(x) is well-formed in an arbitrary
>>    namespace.
>> 
>> but I'm not certain I have that right either. 
>
> hm...what about
>
>   if range_begin() can be found in namespaces associated with
>   x.

Not quite right, because range_begin() denotes a function taking no
arguments.  You really should say

   range_begin(x)

because it's an expression; it accounts for default arguments,
function templates, derived->base conversions, etc.

> OTOH, isn't that just ADL?

Yes, but the way you described it is just not correct; that's all.
Oh, and I suppose an overload of range_begin in the global namespace
would be found, provided it was declared before its point of use.
That's why something like

  range_begin(x) if range_begin(x) is well-formed

is more accurate.

>> Are you really
>> detecting whether range_begin can be found via ADL? 
>
> No.

Then how are you arranging for the semantics to fall back to x.begin()
when range_begin(x) can't be found?  If you're not really doing that,
you need to fix the docs.

>> I wrote code to do that trick, but I don't remember seeing it in
>> the range lib.
>
> Cool trick, though.

Yes; it's partly due to Doug Gregor.  see
boost/detail/is_incrementable.hpp

> The suggested spec. says that the return-type depends on 4 cases, it
> doesn't state how these cases are implemented. I don't think they need
> to state that.

I don't understand what you're trying to say.  Specific implementation
details are not important, but the precise semantics of each case is
important.

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