"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4241E71B.8060007@boost-consulting.com... | Thorsten Ottosen wrote: | > This changes the extension protocol | > to overiding these three functions: | > | > range_adl_begin() | > range_adl_end() | > range_adl_size() | > | > Any comments before I commit? | > | | There is a larger question of how to handle ADL customization points in | general. I like the approach you're proposing, but I dislike the naming | of the above functions. The "adl" can go, IMO, yes, I would have liked that, but it turned out we clashed with range_size<R>::type | and there should be a | "boost" in there somewhere. 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() are found with ADL from within the heap_clone_allocator: template< class T > T* heap_clone_allocator::allocate_clone( const T& r ) { return new_clone(r); } Free-standing functions seems to have slightly different goals. 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. -Thorsten