On Thu, 14 May 2020 at 14:34, Marcin Jaczewski via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> > > > 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
> > >
> > >
> > > For a lambda, the non-static member function is
> > > synthetic_lambda_type::operator() const, and so the lambda would be
> > > captured as const synthetic_lambda_type&. Consider this call:
> >
> > No. The lambda is the coroutine, not its operator().
>
> You mean that lambdas have special wording that make them behave
> different to local objects with member function that return task?

No. The task<void> nonsense confused me.

> For me this is more case of data race, handle to coroutine should be
> destroyed before lambda object is destroyed too.
> This mean `task<>` should cancel request or block until it is
> finished, then we do not have any problems there.

Well, yeah. If I have a member function coroutine, and I invoke it for
a temporary object,
that object is dead when the coroutine resumes. For lambdas, we could
copy the lambda captures
into the coroutine state, but we shouldn't do that for classes in general.