https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #6 from Jonathan Wakely ---
Ah yes, this issue is the subject of
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0571r2.html#intermediate_unordered
which is waiting for a new revision from the author.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #5 from Jonathan Wakely ---
(In reply to Tobias Ribizel from comment #2)
> Something similar like common_type invoke_result> would be much safer.
No, there's no requirement that those types have a common type.
You can have two type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #4 from Jonathan Wakely ---
Maybe we could do this:
--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -483,12 +483,16 @@ namespace __detail
_OutputIterator __result, _Tp __init,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #3 from Jonathan Wakely ---
e.g. https://en.cppreference.com/w/cpp/algorithm/accumulate is clear that the
accumulator has the same type as the init parameter, and there's even a caveat
about it:
https://en.cppreference.com/w/cpp/algo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #2 from Tobias Ribizel ---
I agree, but that doesn't make it less bug-prone IMO, with the narrowing
conversion happening deep inside the exclusive_scan implementation (-Wnarrowing
doesn't pick it up). Something similar like common_ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109229
--- Comment #1 from Jonathan Wakely ---
This is how all standard algorithms that take an initial value work.
