PoC: For Each (Range) Index

[samayala22]

Proof of concept for feature proposed in #551

A few notes:

• I firmly believe that increment should not be part of the API and the called function should have the responsibility to handle any sort of increment. The fact that TBB doesn't have an increment argument supports my point.
• I don't understand why begin, end (and the removed step) are implemented as different template arguments ? They should be the same integral types ? Am I missing something ?
• This is a PoC so the code is not intended to be merged as is.

Minimal example code of the new functionality:

#include <taskflow/taskflow.hpp>
#include <taskflow/algorithm/for_each.hpp>

#include <iostream>
#include <mutex>

int main() {
    tf::Executor executor;
    tf::Taskflow taskflow;
    std::mutex mutex;

    auto init = taskflow.placeholder();
    auto body_index = taskflow.for_each_index(0, 10, [&](int i) {
        std::scoped_lock lock(mutex);
        std::cout << "Hello from task " << i << std::endl;
    });

    auto body_range = taskflow.for_each_index(0, 1000, [&](int b, int e) {
        std::scoped_lock lock(mutex);
        std::cout << "Hello from task range [" << b << ", " << e << ")" << std::endl;
    });

    init.precede(body_index);
    body_index.precede(body_range);

    executor.run(taskflow).wait();
    
    return 0;
}

[tsung-wei-huang]

@samayala22 The reason why input, output iterator types are templated is that applications may mix the use of stateful iterators, constant, or non-stateful iterators. For example:

std::vector<int>::iterator itr;
tf.for_each(1, std::ref(itr), ...)
tf.for_each(1, 100, ...);
tf.for_each(std::ref(itr), 100, ...)
...

[bangerth]

This is a topic of interest to me. So here are a couple of comments.

[bangerth]

The comment in the PR is specifically about this part of the patch. The begin and end iterators, b and e may sometimes be of different types and I think it is useful to retain the ability to have different types as was there before.

[bangerth]

Separately, though, I think it is important to keep the original interface for backward compatibility. Perhaps you want to overload the function by providing a second version that takes the two-argument function (instead of modifying the existing function)? You can use std::enable_if_t to ensure the right one gets called.

[bangerth]

This might be easier to read as follows :-)

Suggested change

	std::disjunction<is_index_func<T_t, C>, is_range_func<T_t, C>>::value,
	is_index_func<T_t, C>::value || is_range_func<T_t, C>::value,