...

Is there any reason the numeric algorithms in Boost.Range (accumulate(), inner_product(), etc.) are located in boost/range/numeric.hpp rather than in files named boost/range/algorithm/<algorithm-name>.hpp like every other algorithm? I think it's confusing for users who expect the uniform file naming convention that Boost.Range applies to other algorithms, to apply to these ones too.

I do find it a little surprising that there's boost/range/algorithm/*.hpp, but only boost/range/numeric.hpp.

I would be surprised to have a boost/range/algorithm/accumulate.hpp, but so long as numeric.hpp continues to exist, it's not such a bad thing.

Would you envision boost/range/algorithm.hpp pulling in the numeric algorithms? I don't think the minor coupling implied is too bad, I'm just curious.

I find the current numeric versus algorithm division as sensible as it is in the standard library -- and since I dealt with that for a long time before discovering boost.range, it didn't surprise me too much. Those coming at it a different way may feel differently, of course.

Ah, I didn't realize there was a similar distinction in the standard library. It surprises me a little, particularly for accumulate() which I view as a generic 'fold' operation, rather than something 'numeric'. But it makes sense that Boost.Range follows the conventions of the standard algorithms it wraps. Regards, Nate