joboccara/pipes

Execution policy

Closed this issue · 4 comments

This is an enhancement suggestion.

Do you plan to implement any execution policy ?
My underlying question is are you willing to stick to C++14 or do you plan to move on to C++20 ?

I understand that dealing with unsequenced policies may be unseasy according to the library design,
but the following would be nice :

inputs
   >>= pipes::transform(std::execution::par, [](auto arg){ return arg * 2; }) // parallel execution
   >>= pipes::filter([](auto arg){ return arg < 42; })
   >>= pipes::push_back(results)
;

or maybe :

inputs
   >>= pipes::transform<std::execution::parallel_policy>([](auto arg){ return arg * 2; }) // parallel execution
   >>= pipes::filter([](auto arg){ return arg < 42; })
   >>= pipes::push_back(results)
;

Ps : Keep up the good work 👍

I was intending to stick to C++14 for a while longer, until C++17/C++20 becomes more ubiquitous on development environments, or if there was a major design change in the library.
As for the idea of execution policy, yes it would be nice. Tbh I'm not familiar with their implementation in C++17. Do you think this is something we could implement for pipes in C++14?

From my point of view, the further a project is from the latest standard, the more difficult the transition - therefore the redesign / refactoring - will be.

Well I did not check every execution policies implementations. To me, it's just a marker type used for templates specialization.

Btw, a bit of self-promotion here : I'm writing a book (and a talk as well) about technical debt. here's the current draft (still a WIP) https://gist.github.com/GuillaumeDua/950695f99b23fb13a934ac88bf27d828.

Ok then, I'll close the issue for the moment.
Your books looks very interesting! Keep up the good work

As conclusion, I'd say designing a road-map to plan standards migration may be a valuable investment, even if not implemented any time soon.

Also, from my point of view, execution policies may comes handy when working with large collections, or complexes functors.