Boost logo

Boost :

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

Thorsten Ottosen <nesotto_at_[hidden]> writes:

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


      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

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