hpx
hpx copied to clipboard
Add C++23 fold algorithms
C++23 added the following fold
algorithms:
-
ranges::fold_left
(https://en.cppreference.com/w/cpp/algorithm/ranges/fold_left) -
ranges::fold_left_first
(https://en.cppreference.com/w/cpp/algorithm/ranges/fold_left_first) -
ranges::fold_right
(https://en.cppreference.com/w/cpp/algorithm/ranges/fold_right) -
ranges::fold_right_first
(https://en.cppreference.com/w/cpp/algorithm/ranges/fold_right_first) -
ranges::fold_left_with_iter
(https://en.cppreference.com/w/cpp/algorithm/ranges/fold_left_with_iter) -
ranges::fold_left_first_with_iter
(https://en.cppreference.com/w/cpp/algorithm/ranges/fold_left_first_with_iter)
These algorithms are specified as enforcing sequential execution. We should discuss whether those should be added to HPX anyways.
See also: http://eel.is/c++draft/alg.fold
Note 1: Only ranges overloads were proposed. Note 2: What's the argument against integrating them with HPX? If we do, again, we are closer to standards conformance + we could end up with a proof of concept for their parallel versions? Note 3: Is sequential enforcement just because they are under ranges or is it unique to the nature of the fold algorithms? Isn't fold a more generic std::reduce/std::accumulate after all (same problems regarding parallelization should be expected)?
ranges::fold_left_first
and ranges::fold_right_first
return std::optional type (C++17)
ranges::fold_left_with_iter
and ranges::fold_left_first_with_iter
return std::in_value_result (C++23)
so should we enable fold algorithms only if HPX compiled with C++23 std?
ranges::fold_left_first
andranges::fold_right_first
return std::optional type (C++17)ranges::fold_left_with_iter
andranges::fold_left_first_with_iter
return std::in_value_result (C++23)so should we enable fold algorithms only if HPX compiled with C++23 std?
No, we should have those algorithms such that people can use them with C++17, if needed.
We would have to deviate from the standard.
We could alternately work on hpx::in_value_result
that does seem better.
We would have to deviate from the standard. We could alternately work on
hpx::in_value_result
that does seem better.
Yes, that would have to be added as well. I thin pre-c++23 these should be in namespace hpx::experimental
, starting C++23 they should be in namespace hpx
.
sure, do we have a hpx::optional? if so do you suggest returning it instead of std::optional? If not, do we plan on implementing it?
sure, do we have a hpx::optional? if so do you suggest returning it instead of std::optional? If not, do we plan on implementing it?
Yes, please use hpx::optional
, it will fall back to std::optional
, if available (see: https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/datastructures/include/hpx/datastructures/optional.hpp).
Update the CMakeLists.txt file of your project to set the appropriate C++ standard and compiler flags. Add the following lines to enable C++23 features: set(CMAKE_CXX_STANDARD 23) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Wpedantic")