On 14/05/2020 19.11, Ville Voutilainen wrote:
> On Thu, 14 May 2020 at 19:01, Avi Kivity via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>> Of course a.then(b) can be folded together into a single coroutine
>> (faster and simpler). But I have many other primitives.
>> smp::submit_to(func) runs a function on another core.
>> parallel_for_each(container, func) will run func in parallel for each
>> element (just on this core). Some primitives internally use .then() to
>> chain calls, so I can't do the merging.
>>
>>
>> Working with lambdas was a minefield of use-after-frees, I was hoping
>> coroutines would free me of that, but it turns out to be just another
>> minefield.
> Righty right. future::then is not such a minefield because the payload
> is in the shared state of the future,
> and it's just moved/shared to what the .then handler will receive, so
> nothing can dangle there.


It is a different kind of minefield. Indeed this particular problem does
not occur, but many others do.


> With coroutines, you need to be a tad more careful. You said you don't
> want more allocations, but, well,
> to avoid dangling, you necessarily need to allocate the things that
> would otherwise dangle.


There already is an allocation, for the coroutine frame, that has
exactly the correct lifetime and is managed automatically. If the
language can see that the object I'm using is temporary, it can do this
little extra thing for me and allocate space for it in the frame and
copy it. It knows that storing a pointer to an rvalue can't end well.