https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Ville Voutilainen from comment #12)
> It sure seems to me that a coroutine lambda's captures should be copied to
> the coroutine state. I don't think the standard says that anywhere.
Maybe I am missing your point (some of these things were decided long before I
joined the fray)
----
Well, the standard is pretty much silent on coros + lambdas. However, the
implementors (Richard, Gor, me, et al) had a long discussion on the topic
before Prague - and took what we could from that to Core.
GCC does not comply with the (agreed in that discussion) intent that the
capture object should be treated in the same manner as 'this', and a reference
passed to the traits lookup, promise parms preview and allocator lookup. I
have a patch for this (will post this week) - but the only implementation with
this correct so far is MSVC
clang passes a ref to the traits but does not pass anything for the closure
object pointer to promise param preview or allocator)
GCC currently passes the object pointer to all three.
====
The idea of bringing the lambda's captures into the coro frame was what I
originally implemented. Richard pointed out that this is wrong when the lambda
is mutable (see gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)
so if one has
auto X = [...] () -> some_coro<xxx> {};
X must exist for the duration of the lambda coro [it was pointed out by Lewis
that really this is only the same as saying that if you have a class with a
member function lambda, the instance of that class has to persist for the
duration of the coro].
We are, I believe, collectively agreed that this is a 'foot gun' (and rvalue
refs doubly so); however, making a better mousetrap here might require some
considerable thought.
I'm happy to be educated if there's some different consensus as to what to do,
and to amend the GCC impl. accordingly.
