Async-await on stable Rust!

[rikki cattermole]

On 09/11/2019 2:24 AM, Sebastiaan Koppe wrote:
> On Friday, 8 November 2019 at 10:36:05 UTC, rikki cattermole wrote:
>> This is a better article from one of the sites you linked: 
>> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ 
>>
> 
> Yes, that is a good one.
> 
>> After reading this, I can confidently say that this is not the problem 
>> I am trying to solve.
> 
> I understand. I just wanted you to be aware of it.

I am, but thanks for the reminder.

>> To me async/await is synchronously executed when a closure is ready to 
>> execute.
> 
> What does 'ready to execute' mean? And why synchronously? isn't the idea 
> of async to run concurrently?

So ready to execute could mean that a socket has data in the buffer 
ready to be read.

So I'm treating async as if it its synchronous from a language design 
point of view, but if you want it to be asynchronous it can be. It 
should depend upon the library implementation its calling into.

In other words, I don't want this behavior baked into the language. That 
seems like a good way to have regrets that we can't fix easily.

>> However, that doesn't mean it can't work with my existing idea ;)
>>
>> Nursery nursery;
>>
>> nursery.async {
>>     ....
>> };
>>
>> nursery.async {
>>     ....
>> };
>>
>> return; // nursery.__dtor == run
> 
> Except that you would want to run immediately, and then joinAll on the 
> __dtor. For it is perfectly possible to have a long living nursery; the 
> one at the root of the program for instance.
> 
> E.g
> 
> ---
> with (Nursery()) {
>    async {
> }

Indeed that was a very simple example. But throw in a copy constructor + 
destructor pair, you should be able to build up a nice little tree on 
the Nursery implementation instance. Which from what I read could be 
quite useful with executing the closures.