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

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-17 09:15:57

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> David Abrahams <dave <at> boost-consulting.com> writes:
>
>> 
>> Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:
>> 
>> > David Abrahams <dave <at> boost-consulting.com> writes:
>
>> > 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.
>
> 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.
>> 
>> ?
>
> well, it might sound really like someting in the standard, 

That's not what I'm trying to achieve at all.

> but it also appears fairly cryptic to me. 

What's cryptic about it?  Here are a few other options that are
similarly precise:

   range_begin(x) if it would result in range_begin being found by
   argument dependent lookup.

   range_begin(x) if there is a matching range_begin in a namespace
   associated with the type of x.

> If the only problem was
> that ADL applies to function overloads (or names in general), then
> why not just strip the "(x)":
>
> range_begin(x) if range_begin can be found by ADL
>  
> ? Wouldn't this account for all names (not just function overloads)?

It lacks precision; it doesn't force that range_begin that's found to
be in a namespace associated with the single argument x.  Just because
there's a range_begin that *can* be found via ADL doesn't mean it will
be found in that expression.  This is nitpicky, but I think the
language is slightly clearer.

>> > 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.
>
> this precense is already needed with the boost::begin() requirement.
> then we also need to revise how the using declaration is used and it
> becomes impossible, IIUIC, to have a fall-back mechanism, in this
> case t.begin() (because one does not have to include the header
> where this fall-back is provided)
>  
>> As long as the concept is coupled to namespace boost there's little
>> point in removing boost_ from the customization point.
>
> well, it means  that the customization point can be use in other context
> independent of boost. It no longer belongs to boost. Quite important.

Maybe you're right.

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