Stream: wg-async-foundations

Topic: Async "block"?


nagisa (Jul 10 2019 at 16:59, on Zulip):

Is the async block really a thing? What’s the motivation for it to not share syntax with closures?

nagisa (Jul 10 2019 at 17:01, on Zulip):

The RFC suggests that my initial assumption about what async blocks are was correct. I guess we Ruby now.

Florian Gilcher (Jul 10 2019 at 17:08, on Zulip):

I'm fine with "Ruby"ing, even if I don't know what the term means?

centril (Jul 10 2019 at 17:09, on Zulip):

Ostensibly it means "Taking inspiration from Ruby's design"?

centril (Jul 10 2019 at 17:12, on Zulip):

What’s the motivation for it to not share syntax with closures?

@nagisa there's a semantic difference here; async { ... } makes an impl Future whereas async || .. makes a closure that makes an impl Future

centril (Jul 10 2019 at 17:13, on Zulip):

Tho async closures may be the redundant thing

nagisa (Jul 10 2019 at 17:13, on Zulip):

I was refering to ruby’s syntax being full of magic, often unnecessary magic, and thus being less easy to deal with.

nagisa (Jul 10 2019 at 17:15, on Zulip):

What’s the motivation for it to not share syntax with closures?

nagisa there's a semantic difference here; async { ... } makes an impl Future whereas async || .. makes a closure that makes an impl Future

Hmm, okay. Still feels weird. In my head async {} eventually becomes just the body of Future::poll after some generator-like transformations and whatnot. Or something similar.

nagisa (Jul 10 2019 at 17:15, on Zulip):

It is still semantically a function.

centril (Jul 10 2019 at 17:30, on Zulip):

Yes sure, that much is true, tho there's one less level of indirection.

@nagisa I prefer to think in more monadic terms; impl Future<...> being a container with a value inside

centril (Jul 10 2019 at 17:30, on Zulip):

so "it's still semantically a function" is taking a more "low level" perspective

nikomatsakis (Jul 10 2019 at 18:13, on Zulip):

Hmm, I too find async block fairly natural -- an "async thing" is something that, when you interact with it "normally", you get back a future to the result instead of the original.

So an async fn is a function that, when called, gives you a future (instead of the result).

Similarly an async { .. } is a block that, when executed, gives you a future (instead of the result).

An async closure async || then is a closure that, when called, gives you a future (instead of the result).

Similarly async fn foo() and fn foo() { async { } } are basically equivalent, as is async || { ... } and || async ... }.

nagisa (Jul 10 2019 at 18:37, on Zulip):

@nikomatsakis but it acts nothing like a block – or rather scope – that we have currently. That’s where most of my "ewww" reaction is coming from.

nikomatsakis (Jul 10 2019 at 18:38, on Zulip):

how so?

nikomatsakis (Jul 10 2019 at 18:38, on Zulip):

it produces a value which, when awaited, executes

nagisa (Jul 10 2019 at 18:38, on Zulip):

I find the limitations around control flow inside async {} unnatural, for one.

nagisa (Jul 10 2019 at 18:39, on Zulip):

async {} looks and feels like it ought to behave like the usual scope, but I now know that it is not the case.

nagisa (Jul 10 2019 at 18:40, on Zulip):

(I do understand where those limitations are coming from, what I disagree with is the syntactic representation of whatever produces this impl Future).

nagisa (Jul 10 2019 at 18:41, on Zulip):

Perhaps it is easiest to compare it with unsafe {} vs {} – both still act like your plain scopes. Hope that makes sense.

nagisa (Jul 10 2019 at 18:41, on Zulip):

(I do also understand that there is nothing I can change here at this point, since the RFC got accepted a long time ago and its my own fault I didn’t follow it)

Last update: Nov 18 2019 at 02:10UTC