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