`<numeric>`: `transform_inclusive_scan` passes output values to the binary (reduce) operation

[akrivx]

Describe the bug

The overload of transform_inclusive_scan that takes execution policy and initial value arguments passes the result of dereferencing the output iterator to the binary reduce operation.

Doing so requires that the output value type can be converted to the types expected by the binary operation.

Command-line test case

See this example here: https://godbolt.org/z/4fscYPcTW
It's working fine with the latest gcc.

Expected behavior

transform_inclusive_scan does not pass the result of dereferencing the output iterator to the binary operation.

STL version

Microsoft Visual Studio Community 2022 (64-bit)
Version 17.6.2

[achabense]

&& transform_exclusive_scan(execution::par,...) has the same problem.

It seems the usage of _Apply_inclusive_predecessor is wrong here.

STL/stl/inc/execution

Lines 4841 to 4847 in 15aea98

	// Apply the predecessor overall sum to current overall sum and elements
	if (_Prev_chunk->_Get_available_state() & _Sum_available) { // predecessor overall sum done, use directly
	_Chunk->_Apply_inclusive_predecessor(_Prev_chunk->_Sum._Ref(), _Dest, _Last, _Reduce_op);
	} else {
	auto _Tmp = _Get_lookback_sum(_Prev_chunk, _Reduce_op);
	_Chunk->_Apply_inclusive_predecessor(_Tmp, _Dest, _Last, _Reduce_op);
	}

[frederick-vs-ja]

It seems that we should pass _Transform_op to _Apply_inclusive_predecessor (with its signature changed) and use _Transform_op in it.

We should also pass the beginning "input" forward iterator. Perhaps we should avoid moving.

Edit: The standard doesn't seem to require parts of output range (whose element type is the value type of ForwardIterator2) to be usable as mediate results (whose element type should be T). Perhaps we need to create a new T sequence when it's impossible to reuse the output range.