20

In C++20, many (most?) C++-standard-library algorithms have been made constexpr. Yet - std::accumulate has not.

It seems like it could have been:

template<class InputIt, class T>
constexpr T accumulate(InputIt first, InputIt last, T init)
{
    for (; first != last; ++first) {
        init = std::move(init) + *first;
    }
    return init;
}

So - is there a reason it wasn't constexpr'ed as well?

Note: This question was motivated by my answer to this question on compile-time accumulation.

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • I personally don't see any. Maybe it has just been forgotten? C++20 is not yet adopted, maybe you should propose, or would that be too late already? – Aconcagua Sep 19 '19 at 07:39
  • Looks like [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html) focusses on the `` header, and nothing in `` has yet been `constexpr`-ed. – BoBTFish Sep 19 '19 at 07:39
  • 9
    It was proposed (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1645r0.html). I guess they just didn't get to it. – StoryTeller - Unslander Monica Sep 19 '19 at 07:40
  • @Aconcagua: Too late I think. Maybe national bodies could demand it. – einpoklum Sep 19 '19 at 08:26
  • @StoryTeller: I just asked Ben Deane, let's hope he answers. – einpoklum Sep 19 '19 at 08:29
  • FWIW, all the generic algorithms in `` aren't affected by the `constexpr` addition. They aren't affected by the ranges update either. – L. F. Sep 19 '19 at 10:04
  • @L.F.: Yeah, that's also a bit dodgy. But you can at least say that adding `std::ranges::accumulate` and all the rest of those is a lot of lines of code to add, and there's need to harmonize things with ranges-v3 and so on - while adding `constexpr` should be a trivial change. – einpoklum Sep 19 '19 at 10:09

2 Answers2

9

P1645R1 was actually adopted in the Belfast meeting for inclusion in C++20 in response to NB comment US 320.

As a result, all of the following algorithms will be constexpr in C++20 (except for the overloads of them that take an ExecutionPolicy):

  • accumulate
  • reduce
  • inner_product
  • transform_reduce
  • partial_sum
  • exclusive_scan
  • inclusive_scan
  • transform_exclusive_scan
  • transform_inclusive_scan
  • adjacent_difference
  • iota
Barry
  • 286,269
  • 29
  • 621
  • 977
4

TL;DR;

There is a proposal in process. We won't know the result until the process is done but it won't make C++20.

Longer answer

There was indeed a proposal: constexpr for algorithms, quoting the relevant part:

This proposal is to add constexpr to the following function templates in , excepting the function templates that accept an ExecutionPolicy.

  • accumulate

...

We can see from the cplusplus/papers issue 432 that the paper was moved to Language Evolution Working Group:

R0, needs to be looked at / forwarded by LEWG. Removing the LWG tag.

and the milestone was moved to 2019-11:

modified the milestones: 2019-07, 2019-11

which would be the upcomoing Belfast meeting, so it will not make C++20.

Community
  • 1
  • 1
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • But what's the _reason_ for not doing the trivial addition of constexpr? – einpoklum Sep 21 '19 at 07:39
  • 1
    @einpoklum because it is not a change that can be done editorially, there is a process. It needs a proposal which we have. The proposal needs to go through LEWG and then LWG. If not issues are found then it can be applied to the standard. The answer is that this is process and we won't know the result until the process is over. – Shafik Yaghmour Sep 21 '19 at 12:06
  • If you can add this elaboration to your answer, I can accept it. – einpoklum Sep 21 '19 at 13:50