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

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

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> David Abrahams <dave <at> boost-consulting.com> writes:
>
>> 
>> Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:
>
>> > 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,
>
> right, this is true.
>
>> function templates,
>
> specializations are found too, but we don't document what to
> specialize (eg. boost::range_detail::range_begin())

That's not what I mean.  I mean that if the user writes a function
template called range_begin in his Range's namespace it will be found.

>> derived->base conversions, etc.
>
> these won't happen as the default implementation is the one in
> namespace boost::range_detail which is a function template.

I see, because of the default, as you say later.

>> > 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.
>
> no, it wouldn't: the global namespace is never searched and 
> the default is chosen then

Ah, okay.

> so a bit the same reason that a base class version won't work
> either.  (arguably the base class version should be found, but
> that's a different story)
>
>> That's why something like
>> 
>>   range_begin(x) if range_begin(x) is well-formed
>> 
>> is more accurate.
>
> I thinks ADL is the only mechanism that will valid here.

I think you're probably right.

> So with the change
>
>   if range_begin(x) can be found by ADL
>
> I think we nailed it. 

What you _mean_ is correct, but that's not phrased right.  ADL find
function overloads, not expressions.  That's why I wrote

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

How about

   range_begin(x) if it would invoke a function found by argument
   dependent lookup.

?

> This should implicitly account for default 
> arguments, but I don't think we need to mention that.
>
> As a related issue, how was everyone feeling about range_begin()
> instead of boost_range_begin()?

I'm ambivalent.  There are no really good answers to this dispatching
question, only compromises.  By dropping boost_ you increase the
chance of a semantic collision, but you make the name more general.  I
don't think it makes sense to make that change unless you're also
going to change the concept requirements from

      boost::begin(x) is valid

to 

      range_begin(x) is valid

and just tell people that the standard containers and builtin arrays
only model ranges in the presence of some range_begin overloads
provided by the library.

As long as the concept is coupled to namespace boost there's little
point in removing boost_ from the customization point.

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