foreach(x; tuple_like)
{
    // ...
}
//versus
for_each(tuple_like, [&](auto x)
{
    // ...
});

// runtime
for_each(range, [](auto x)
{

});
// compile-time
for_each(tuple_like, [](auto x)
{

});

void advance(RandomAccessIterator it, Distance n);

E>Ну бывают же не только пары итераторов, но и тройки, скажем, или, наоборот, одинокие итераторы, например итератор элемента std::list'а...

template <typename I> // I models Linked Iterator
I reverse_append(I first, I limit, I result)
{
    while (first != limit) {
        I old_successor = successor(first);
        set_successor(first, result);
        result = first;
        first = old_successor;
    }
    return result;
}

E>Ну бывают же не только пары итераторов, но и тройки, скажем, или, наоборот, одинокие итераторы, например итератор элемента std::list'а...

interface OnePassRange {
   bool empty();
   Ref<T> front();
   void popFront();
}

E>>Ну бывают же не только пары итераторов, но и тройки, скажем, или, наоборот, одинокие итераторы, например итератор элемента std::list'а...

Another example of an iterator-based design that's not easy to replicate with ranges is Boost Multi-Index. (Thanks Emil Dotchevski for pointing that out during my talk. (Marshall Clow promised the video will be available Real Real Soon Now(tm).)) In Multi-Index, indexes store iterators; storing ranges would often waste twice the space for little
or no benefit.

FR>interface OnePassRange {
FR>   bool empty();
FR>   Ref<T> front();
FR>   void popFront();
FR>}
FR>

Another weakness I noticed is visible when translating STL algorithms that return one iterator, such as find, which has this signature:

It find(It b, It e, E value)

where It is a one-pass iterator type and E is the type referenced by the iterator. STL's find returns the first iterator iter between b and (excluding) e that satisfies *iter == value. Once that iterator is returned, you can combine it with b to obtain the range before value, or with e to obtain the range after value.

Ranges lack such capabilities. The range-based find has this signature:

Range find(Range r, E value)

It consumes from r until it finds value and returns what's left of r. This means that you get access to the portion after the found value, but not before.

Fortunately, this problem is easily solved by defining a new range type, Until. Until is a range that takes another range r and a value v, starts at the beginning of r, and ends just before r.front() == v (or at the natural end of r if v is not to be found). Lazy computation for the win!

EP>foreach(x; tuple_like)
EP>{
EP>    // ...
EP>}
EP>//versus
EP>for_each(tuple_like, [&](auto x)
EP>{
EP>    // ...
EP>});
EP>

EP>Имхо, ничего страшного

import std.stdio;

void print_type(A...)(A a)
{
    foreach(T; A)
        writeln(typeid(T));
}

void main()
{
print_type(1, 2.0, "3");
}

struct PrintType
{
    template<typename T> void operator()(T) const
    {
        std::cout << typeid(T).name() << std::endl;
    }
};

template<typename ...Ts>
void foo(Ts...)
{
    using namespace boost::mpl;
    for_each<vector<Ts...>>(PrintType());
}

template<typename ...Ts>
void foo(Ts...)
{
    using namespace boost::mpl;
    for_each<vector<Ts...>>([](auto x)
    {
        std::cout << typeid(decltype(x)).name() << std::endl;
    });
}

void print_type(A...)(A a)
{
    foreach(T; A)
        writeln(typeid(T));
}
// versus
template<typename ...Ts> void foo(Ts...)
{
    for_each<Ts...>([](auto x)
    {
        writeln(type_name(decltype(x)));
    });
}