Thorsten Ottosen <nesotto@cs.aau.dk> 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
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 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. 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