[boost] Re: [range] update on ADL hooks

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-23 18:30:01

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:4241EFF2.3040605_at_boost-consulting.com...
| Thorsten Ottosen wrote:
| > "Eric Niebler" <eric_at_[hidden]> wrote in message
| > | I suggest:
| > |
| > | boost_range_begin()
| > | boost_range_end()
| > | boost_range_size()
| > |
| > | In general, boost libraries that use ADL customization points should
| > | name the functions:
| > |
| > | boost_[library]_[function]()
| > |
| > | The idea is that these overloads are going to appear in users' code, in
| > | their namespace. From a maintenence standpoint, "boost_range_begin"
| > | announces more clearly that this function has to do with the Boost.Range
| > | library than "range_adl_begin".
| > |
| > | Comments?
| >
| > I do like that convention for boost.range.
| > But it doesn't seem to apply to all ADL customization points;
| > for example, in the pointer container lib
| >
| > new_clone()
| > delete_clone()
| >
|
|
| But we can still come up with a convention used by any *new* ADL
| customization points. That's what you're asking about anyway, right?

yes, agreed.

| >
| > Free-standing functions seems to have slightly different
| > goals.
|
|
| You lost me. What goals?

that boost:::foo() does ADL.

new_clone() is used primarily inside the
containers and does therefore not suffer much
inconvenience.

| >
| > One consequence of using the name
| > boost_range_begin() is that the users code won't
| > work with the next standard library. I would like to retain
| > compatibility if possible.
| >
|
|
| First, there's just no reasonable expectation that boost libraries
| should be forward-compatible with some future version that gets accepted
| into the standard. Libraries change as they go through standardization
| -- that's expected. And second, the standardization committee might
| reason like I did and decide that "std_range_begin()" is a better name
| than "range_adl_begin()", and you've lost compatibility anyway.

true, that could happen. the difference being that we might not.
In some sense it also seems wierd that the same customization point
should have different points in different libararies. Seems redundant.

Another set of names could be

begin_range()
end_range()
size_range()

-Thorsten