Thorsten Ottosen wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:umzstxh18.fsf@boost-consulting.com... | "Eric Niebler" <eric@boost-consulting.com> 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