On Fri, 18 Dec 2020, 23:42 Kai via Gcc-help, <gcc-help@xxxxxxxxxxx> wrote: > On 18/12/2020 23:49, Jonathan Wakely wrote: > > On Fri, 18 Dec 2020, 22:35 Kai via Gcc-help, <gcc-help@xxxxxxxxxxx > > <mailto:gcc-help@xxxxxxxxxxx>> 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. > Returning by value is not expensive in C++17. The values will be moved whenever possible, or the copy will be elided completely. As I wrote, the statement compiles (and works) when policy is > execution::seq - which strikes me as odd... > Failing to meet the function's requirements doesn't mean it definitely won't compile. >
