Boost logo

Boost :

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

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> David Abrahams <dave <at>> writes:
>> Thorsten Ottosen <nesotto <at>> writes:
>> > David Abrahams <dave <at>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at