type_erased feels unnecessary.

[Akira Takahashi <faithandbrave@…>]

type_erased Range Adaptor is in release brunch of Boost 1.46.0, but I feel that this is unnecessary. It is enough if there is any_range:

#include <iostream>
#include <vector>
#include <boost/assign/list_of.hpp>
#include <boost/range/any_range.hpp>
#include <boost/range/algorithm/for_each.hpp>
#include <boost/range/adaptor/filtered.hpp>

typedef boost::any_range<
    int
  , boost::forward_traversal_tag
  , int
  , std::ptrdiff_t
> integer_range;

void disp(int x)
{
    std::cout << x << std::endl;
}

void disp_all(integer_range r)
{
    boost::for_each(r, disp);
}

bool is_even(int x)
{
    return x % 2 == 0;
}

int main()
{
    const std::vector<int> v = boost::assign::list_of(1)(2)(3)(4)(5);

    disp_all(v | boost::adaptors::filtered(is_even));
}

Even if there is few it, I feel that I am premature to include it in 1.46.0 official release.

[Akira Takahashi <faithandbrave@…>]

<del>Even if there is few it, I feel that I am premature to include it in 1.46.0 official release.</del> At least, I feel that it is too early to include type_erased into 1.46.

[Neil Groves]

I didn't feel it was too early to put this into the release branch. The core of the interface design is built upon experience gained with other any_iterator implementations. The implementation of any_interface has been tested in production environments successfully. The inclusion of the type_erased definitely has application particularly when chaining adaptors that are passing results to templatised range algorithms that are not specialised for any_range.

At this point experience shows that the feature is popular and working.

[faithandbrave@…]

The core of the interface design is built upon experience gained with other any_iterator implementations.

I cannot find the experience. Where can it be seen? At least, with the sample on a document, I do not think that it is useful.