https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Avi Kivity from comment #5) > This snippet from cppreference: > > If the coroutine is a non-static member function, such as task<void> > my_class::method1(int x) const;, its Promise type is > std::coroutine_traits<task<void>, const my_class&, int>::promise_type > > implies that both gcc and my interpretation are wrong. gcc passes a pointer > for the lambda, and I'd like the lambda to be passed by value. The > difference between gcc and cppreference is trivial, and both of them make > coroutine lambdas unusable if they contain state and if the lambda is > asynchronous. ( assuming that this is the problem, I haven't yet had a chance to check * could still be a bug ;) ). I have a pending change to pass a reference to the lambda object to the traits, promise preview and allocator lookups. This was a source of considerable discussion amongst the implementors (GCC, clang, MSVC) about how the std should be interpreted. The change I mention will make the lambda capture object pointer behave in the same manner as 'this' (which was the intended behaviour as determined by the long discussion). MSVC implements this now, and clang will be changing to match it also. That won't solve any lifetime issue with the capture object - you will still need to ensure that it exists for the duration of the coroutine * as you would for a class instance with a method coroutine *. We (at least several of us) agree that this is a source of easy programming errors - and I expect there to be some revisiting in c++23. That's a considerable challenge in the face of a mutable lambda - maybe (thinking aloud) needs something like Apple blocks, but with an automatic promotion of the closure to a heap object if it escapes the creating scope.
