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
>> 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
> 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
range_begin(x) if it would invoke a function found by argument
> 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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk