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.