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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-09-17 05:55:42

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, but it also appears
fairly cryptic to me. 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)?

> > 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.

-Thorsten