[boost] range adaptors

Subject: [boost] range adaptors
From: barend (barend_at_[hidden])
Date: 2010-12-28 12:58:32

hi,

First of all I like the new range adaptors, thanks for creating them.

As much of Boost.Geometry is range-based, we like to support them. So I 
recently created a small integration, enabling things as:

int n = boost::geometry::num_points(my_line | filtered(not_two()));

where it filters out the points having a coordinate with 2 (just for 
testing). It works great, and most the adaptors, like strided, sliced, 
uniqued, reversed, seem very useful to me in this context.

To enable this use I needed to specialize one of our structures to match 
boost range adaptors, like this:

template<typename Filter, typename Geometry>
struct tag<boost::range_detail::filter_range<Filter, Geometry> >
{
     typedef typename geometry::tag<Geometry>::type type;
};

This was all that was necessary to enable range adaptors.

I now discover that their names are recently changed, from filter_range to 
filtered_range, etc (to match the adaptors, understandable).

Of course library developers may do these things in a namespace called 
range_detail, but I've some questions:

- do you encourage or support or discourage using filtered_range etc. in 
library code? Namespace range_detail is normally not used by library users, 
but there is no other way for us to adapt them: the filtered function 
returns a range_detail::filtered_range struct, and we have to specialize on 
that specific struct...

- if this is a generic need, would it not be better to move them out of 
namespace *detail?

- I noticed that sliced and copied are not in namespace range_detail but in 
adaptors, for me that sounds OK, but it is expected that for consistancy it 
might move namespace in any future

- are there more changes on the way?

Regards, Barend