"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4242F9E4.4090500@boost-consulting.com... | Thorsten Ottosen wrote: | says, it suggests an association with the iterator_range<> type. But | also, in my understanding, the Range concept is a bit more inclusive | than merely "iterator ranges". A std container satisfies the Range | concept, doesn't it? yes. | Consider iterator_range_size(). I could have a | container that satisfies the range concept for which .size() is an O(1) | operation, but std::distance( .begin(), .end() ) is O(N). What Big-O is | suggested by "iterator_range_size()" when applied to one of those contaiers? O(1) but boost::size(a_range) is allowed to be O(N) | So, our concern here is that someone could borrow boost's Range concept | without using boost's Range code? But this is still boost's Range | concept, so I'm not sure I agree with Dave that there is "no Boost | relationship in sight". But I'll put that aside and plan for a future | when the Range concept is widely recognized outside Boost. Calling it | "range_begin()" leads to conflicts, but can they be resolved? Can we | move the conflicting template into a different namespace? I think so. Let's assume we want the functions to be named namespace boost { range_begin(); range_end(); range_size(); } then we can put the metafunctions into a namespace like namespace boost { namespace range { struct iterator; struct const_iterator; struct value; struct size; struct difference; } } The implementation then does namespace boost { template< class T > typename range::iterator<T>::type begin( T& r ) { return range_begin(r); } } To summarize this extension protocol - put range_begin() etc in your types namespace - (partial) specialize range::X for all X The library protocol would be - put library name as prefix on ADL hooks - put metafunctions in a namespace with the name of the library -Thorsten