"Eric Niebler" <eric@boost-consulting.com> writes:
So, our concern here is that someone could borrow boost's Range concept without using boost's Range code?
Or they might wish to provide something that would match the Range concept if used with Boost (or some other library that has adopted it) without actually using any Range code at all.
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".
The point is that once the customization point is released to the public, lots of different code may use it for its own purposes. Some library A may advertise that it accepts types modeling the Range concept. Now library B wants to work with library A so it provides the hooks. Nobody's using Boost! The concept may have come from Boost, but it no longer belongs there. And one day you might want to standardize these hooks without invalidating existing libraries that use them.
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?
Not so easy. If you want to avoid trouble with GCC, you really have to pick a name that's unlikely to be used for anything else !&*%(^#@!! Anyway, I'm not totally opposed to boost_range_whatever, I just wanted to make sure that all the arguments were well understood. -- Dave Abrahams Boost Consulting www.boost-consulting.com