<numeric> Implement P1645R1 "constexpr for <numeric> algorithms"

[Neargye]

Description

This is an in-progress implementation of constexpr <numeric>.
Will resolve issue #337.

Checklist

• fix P1645R1 constexpr For <numeric> Algorithms #337

Be sure you've read README.md and understand the scope of this repo.

If you're unsure about a box, leave it unchecked. A maintainer will help you.

• Identifiers in product code changes are properly _Ugly as per
  https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
• The STL builds successfully and all tests have passed (must be manually
  verified by an STL maintainer before automated testing is enabled on GitHub,
  leave this unchecked for initial submission).
• These changes introduce no known ABI breaks (adding members, renaming
  members, adding virtual functions, changing whether a type is an aggregate
  or trivially copyable, etc.).
• These changes were written from scratch using only this repository,
  the C++ Working Draft (including any cited standards), other WG21 papers
  (excluding reference implementations outside of proposed standard wording),
  and LWG issues as reference material. If they were derived from a project
  that's already listed in NOTICE.txt, that's fine, but please mention it.
  If they were derived from any other project (including Boost and libc++,
  which are not yet listed in NOTICE.txt), you must mention it here,
  so we can determine whether the license is compatible and what else needs
  to be done.

[miscco]

I did implement the same changes earlier this week but didnt manage to push them / write the appropriate tests.

Generally this looks already quite good. All the comments apply to transform_reduce as well.

Also as a side note I would suggest to create smaller commits. Here it might be simple but I would still split them up into logical parts (My branch history looks like this)

[numeric] make transform_reduce constexpr
[numeric] make reduce constexpr
[numeric] make iota constexpr
[numeric] make adjacent_difference constexpr
[numeric] make transform_inclusive_scan constexpr
[numeric] make transform_exclusive_scan constexpr
[numeric] make inclusive_scan constexpr
[numeric] make exclusive_scan constexpr
[numeric] make partial_sum constexpr
[numeric] make inner_product constexpr
[numeric] make accumulate constexpr
[xutility] make _Idl_distance constexpr

[SuperWig]

Shouldn't the is_constant_evaluated comments have ()'s?

[BillyONeal]

Thanks for your contribution @Neargye !

[miscco]

Now I am super late to the party, but wouldnt it be possible to move the is_constant_evaluated branch in here, so that we get the throughput improvement from the if constexpr

    if constexpr (_Plus_on_arithmetic_ranges_reduction_v<_Unwrapped_t<const _InIt&>, _Ty, _BinOp>) {
#ifdef __cpp_lib_is_constant_evaluated
        // TRANSITION, DevCom-878972
        if (_STD is_constant_evaluated()) {
            for (; _UFirst != _ULast; ++_UFirst) {
                _Val = _Reduce_op(_STD move(_Val), *_UFirst); // Requirement missing from N4713
            }
            return _Val;
        }
#endif // __cpp_lib_is_constant_evaluated
        (void) _Reduce_op; // TRANSITION, VSO-486357
        return _Reduce_plus_arithmetic_ranges(_UFirst, _ULast, _Val);
    } else {
        for (; _UFirst != _ULast; ++_UFirst) {
            _Val = _Reduce_op(_STD move(_Val), *_UFirst); // Requirement missing from N4713
        }
        return _Val;
    }

[BillyONeal]

That still has the loop on both branches of the if constexpr, so I don't think it helps.

[StephanTLavavej]

Good question, I've filed #414 to keep track of this.

[miscco]

I think we cannot get rid of the loop in the if constexpr branch as that is the is_constant_evaluated fallback, but this gets rid of the duplication of the loop in the non if constexpr case

[BillyONeal]

Hmm that's fair.