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

From: Eric Niebler (eric_at_[hidden])
Date: 2005-03-24 12:33:24

Thorsten Ottosen wrote:
> "David Abrahams" <dave_at_[hidden]> wrote in message 
> news:umzstxh18.fsf_at_boost-consulting.com...
> | "Eric Niebler" <eric_at_[hidden]> writes:
> 
> | It's not an entirely different argument.  Peter was saying that once
> | you publicize the customization point, it no longer "belongs" to the
> | library.  Imagine what happens if some other library wanted to use the
> | same range concept, but not depend on Boost itself.  Either they'd be
> | picking a new ugly name for a customization point with identical
> | semantics :( or they'd be using the name "boost_range_begin" in code
> | with no Boost relationship in sight :(.
> |
> | As my wife's co-worker says, "it's a two-headed sword" ;-)
> |
> | For that reason, it might be better to use something like
> | "iterator_range_begin" that has a hope of becoming lingua franca like
> | swap.  At least that's how I understand Peter's argument.
> 
> Hm.. yeah...I guess you're better at expressing my point than
> I myself :-)
> 
> iterator_range_ seems to be a good prefix.
> 
> What do you say, Eric, do you like
> iterator_range_begin() etc?
> 

I'm finally beginning to grasp the full implications of Peter's comments 
about customization points. Thanks for the clear explanation, Dave, and 
Thorsten, I now understand what you were saying.

I have a couple of concerns with "iterator_range_begin". First, as Pavol 
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? 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?

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?

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com