Thorsten Ottosen <nesotto@cs.aau.dk> writes:
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,
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 www.boost-consulting.com