transform-reduce compiling with seq but not par - bug?

[Kai]

On 18/12/2020 23:49, Jonathan Wakely wrote:
> On Fri, 18 Dec 2020, 22:35 Kai via Gcc-help, <gcc-help@gcc.gnu.org
> <mailto:gcc-help@gcc.gnu.org>> wrote:
>>
>>     The statement in questions reads (in a simplified example):
>>     Obj x = transform_reduce( execution::par, v.begin(), v.end(), Obj{0},
>>                               [](Obj &a,Obj const &b) { a.combine(b);
return
>>     move(a); },
>>                               [](int i){ return Obj{i}; }  );
>>
> No, I don't think this is a bug in GCC. Your unary_op returns by value,
> which means it cannot be the first argument for your binary_op, because
> that requires a non-const lvalue.
>
> It should work if you change your first lambda to:
>
> [](Obj a,Obj const &b) { a.combine(b); return a; }

Thanks for your quick response. Sure, taking that arg by value works.
But my initial intention was to avoid copying of objects (they might
become large) as much as possible, thus passing by reference or moving.
As I wrote, the statement compiles (and works) when policy is
execution::seq - which strikes me as odd...

Cheers, Kai
--
"Rest your weary head and let your heart decide"
<Queen>
D-55120 Meenz
++ PGP Key fingerprint  059D 4FAA FE93 5928 1B22  7FAF EC08 5BF9 D50E
F933 ++
-----BEGIN GEEK CODE BLOCK-----
VERSION: 3.12
GCS/IT d- s: a++>-----(?) C++$ UL++(++++$) P++ L++$ E-(+) W--(+) N !w---
!O !M V? PS+ PE-() Y+ PGP++ t R@* tv--(-) b+>++ DI++ G e+++(*) h? y?
------END GEEK CODE BLOCK------