Date: Thu, 14 May 2020 14:26:46 +0200
czw., 14 maj 2020 o 14:09 Ville Voutilainen via Std-Proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
> On Thu, 14 May 2020 at 14:59, Avi Kivity <avi_at_[hidden]> wrote:
> >
> > On 5/14/20 2:46 PM, Ville Voutilainen wrote:
> > > On Thu, 14 May 2020 at 14:34, Avi Kivity <avi_at_[hidden]> wrote:
> > >>>> With a lambda coroutine, we have a problem. This is because lambdas are
> > >>>> captured by reference:
> > >>> Says what?
> > >>
> > >> Says the quote below, from cppreference.
> > > Your wording was confusing; I thought you meant a lambda as a
> > > coroutine parameter.
> > > For cases where we are in a non-static member function, the *this is
> > > indeed not copied.
> >
> >
> > Ah, the lambda _is_ a coroutine parameter in a sense, if you follow the
> > regular translation of a lambda to a struct with operator().
> >
> >
> > And note this is not specific to lambdas, it happens for any member
> > coroutine called on a temporary. A lambda is just the most common way of
> > generating such calls.
>
> Right. Calling a member function coroutine of a temporary seems like
> madness to me.
> It's quite like calling a member function that queues async work that
> is later completed in
> some other member of the object.
>
> I'm not sure I understand where the temporary really is in the
> not-so-lame testcase in the bug report. To me,
> it seems like everything is stored and lifetimes don't end
> prematurely, but I don't understand how initial_suspend
> really works. :)
but code like:
```
task<> f()
{
X x;
co_await [&]-> task<> { co_await x(); }();
}
```
should work fine, as lambda object will be destroyed after `x()`
finish and `f` continue.
```
int var;
void f()
{
[](int i)-> task<> { co_await X(); var = i; }(3);
}
```
same here as lambda do not have state and there is nothing to dangle.
But still it could be canceled because handle `task<>` is destroyed
after `;`.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
> On Thu, 14 May 2020 at 14:59, Avi Kivity <avi_at_[hidden]> wrote:
> >
> > On 5/14/20 2:46 PM, Ville Voutilainen wrote:
> > > On Thu, 14 May 2020 at 14:34, Avi Kivity <avi_at_[hidden]> wrote:
> > >>>> With a lambda coroutine, we have a problem. This is because lambdas are
> > >>>> captured by reference:
> > >>> Says what?
> > >>
> > >> Says the quote below, from cppreference.
> > > Your wording was confusing; I thought you meant a lambda as a
> > > coroutine parameter.
> > > For cases where we are in a non-static member function, the *this is
> > > indeed not copied.
> >
> >
> > Ah, the lambda _is_ a coroutine parameter in a sense, if you follow the
> > regular translation of a lambda to a struct with operator().
> >
> >
> > And note this is not specific to lambdas, it happens for any member
> > coroutine called on a temporary. A lambda is just the most common way of
> > generating such calls.
>
> Right. Calling a member function coroutine of a temporary seems like
> madness to me.
> It's quite like calling a member function that queues async work that
> is later completed in
> some other member of the object.
>
> I'm not sure I understand where the temporary really is in the
> not-so-lame testcase in the bug report. To me,
> it seems like everything is stored and lifetimes don't end
> prematurely, but I don't understand how initial_suspend
> really works. :)
but code like:
```
task<> f()
{
X x;
co_await [&]-> task<> { co_await x(); }();
}
```
should work fine, as lambda object will be destroyed after `x()`
finish and `f` continue.
```
int var;
void f()
{
[](int i)-> task<> { co_await X(); var = i; }(3);
}
```
same here as lambda do not have state and there is nothing to dangle.
But still it could be canceled because handle `task<>` is destroyed
after `;`.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2020-05-14 07:29:59