Update on the await syntax after May 23 meeting

[RustyYato]

@stepancheg

The macro could be stabilized first

You keep pushing this, but it has been said, by multiple people and multiple Rust team members that a temporary syntax (macro or otherwise) is not a viable option.

---

@stepancheg

Currently, projects don’t use any async/await because it’s not stable, and stable rust is a hard requirement for lots of projects.

And converting an experimental branch project to async/await is a large amount of non-automatable work people rarely can afford.

@stepancheg

If the macro was stable, people could start actually using macro await, and at the same time can “try” experimental nightly syntax with a simple script which converts macros to any syntax.

You are contradicting yourself here, why would people try a experimental syntax when they have a perfectly good stable syntax?

Using nightly Rust isn't that hard, especially if you are only using it for async/await (which is unlikely to change significantly at this point), so those who would experiment already are, and those who can't experiment won't try the experimental await syntax (especially if there is already a stable option).

@stepancheg

It can be a macro with a simple parser hack.

That isn't a macro, it may look like a macro but it isn't. It requires just as much work as a true keyword so the lang team decided to just go with the keyword.

@stepancheg

Or simply wait! can be a macro. Any would do.

You can try that out now if you want.

[notriddle]

There are already several threads all about possible alternative syntaxes for awaiting, including already-existing discussions about whether await!() is feasible or a good idea. Please move this over to one of the existing threads.

[gus]

I am not trying to reopen this topic at all, but I'm not sure of the appropriate forum to ask a simple questions without a chatroom...

I'm afraid to approach the raw discussion threads and the only explanation in the summaries that I can find for why "method syntax" was not chosen is from withoutboats' "A final proposal for await syntax" blog post:

Await is not a method because it yields control in the same way that ? is not a method. Though users have repeatedly asked why there is not an “Await trait” that defines the await method, the reality is that there is no way to define the await operator as a method. The user defineable part of the await operator is controlled by the Future trait , which defines what happens when the await operator polls the future. This is analogous to the way that the user defineable part of the ? operator is controlled by the Try trait, which does not impact the control flow aspect of the operator.

I don't understand the "because it yields control" objection, and I suspect I'm missing something so obvious that it didn't need to be explained to a better informed audience. Can someone point me to a further discussion of why await couldn't be a method?

As far as I know, methods (or functions) that block until some condition changes are quite common, even in green-thread situations where the thread has to deschedule itself to allow another callstack to execute (or other exciting internal implementations). Given this, the await "semantics" of "an operation you can do to a Future to block and return the resolved value" seem so obviously applicable to a method-call that I don't understand why we were even discussing other postfix alternatives What have I overlooked?

[anp]

The short answer is that async control flow needs to yield out of the containing body, not out of the method itself. A full unpacking of this exists somewhere, but IIUC this is the core of it.

[comex]

@gus

As far as I know, methods (or functions) that block until some condition changes are quite common, even in green-thread situations where the thread has to deschedule itself to allow another callstack to execute (or other exciting internal implementations). Given this, the await “semantics” of “an operation you can do to a Future to block and return the resolved value” seem so obviously applicable to a method-call that I don’t understand why we were even discussing other postfix alternatives What have I overlooked?

There was a long discussion about this and the "async-as-green-threads" analogy in this thread:

On why await shouldn't be a method

The above is mostly based on my experience with async/await in Python where the new syntax was created after the community had experienced with co-routines implemented via yield. There it’s clear how the thread of control goes up and down the call stack. In case Rust async/await works completely differently, then I’ll be happy to be enlightened

[gus]

Aha, thanks!

On reading this discussion thread, I realised my misunderstanding. I previously believed await was only something you did at the “top level” transition from synchronous code to async, to block and resolve a particular Future. Turns out that is quite wrong!

await is instead something you do only in async functions, to basically build an .and_then() chain using a more comfortable inline (procedural) syntax. My understanding of the field-access conclusion then is that we don’t want to hide the yield point deeper in the call-stack (basically green threads) because of the desire for zero-cost abstractions - instead we want to transform the async function directly. This requires compiler transformation magic triggered by the async keyword to “see” the await points, which is why they’re only shallow. More importantly from my pov, in this explanation await is just a necessary sub-part of the async function syntax, and should not be considered something useful/meaningful in itself - and if it’s going to be a syntax hack, it may as well be a “cheap” syntax hack (mentally and compiler-wise). Seeing it instead as an async “quasi-quote” macro syntax explains why a wide variety of postfix proposals were reasonable (in particular exotic sigils suddenly become excusable

Thanks! This has been bugging me since the first “summaries” started appearing.

[Tom-Phinney]

Thanks for above succinct summarization. Perhaps those who are still championing alternate syntax will dig deeper into how the async functionality is implemented and realize why no combination of macros, methods, etc. can provide the required AST transformations.

[matklad]

@Tom-Phinney

why no combination of macros, methods, etc. can provide the required AST transformations

Technical detail: macro syntax is absolutely not restricted to simple AST transformation. The prime example here would be macro_rules which is a macro from the caller's point of view, but is a magical compiler built-in inside. It's also interesting that it is named macro_rules and not macro, presumably do dodge macro-is-a-keyword isse.

In other words, macro call syntax can serve as a placeholder syntax, the implementation doesn't have to be a macro at all (although it often can be a macro that expands to unstable syntax).

[HadrienG]

@matklad

It’s also interesting that it is named macro_rules and not macro , presumably do dodge macro-is-a-keyword isse.

AFAIK, that's because the lang team is unsatisfied with the current design of declarative macros and wants to scrap it in favor of something better that will be called macro once the brain bandwidth is available.

[matklad]

I also have read this thread several times, and I feel bad because:

• I feel negative emotions when I read a discussion in this tone, even if I don’t participate in it myself.

• No one has called-out that the discussion has went wrong, and that sort-of normalizes it.

• On non-meta level, discussion seems very uproductive because two central questions:

  • why don’t we want to start with a placeholder syntax and fill it with real one later?
  • do we feel comfortable stabilizing a syntax which wasn’t baking in nightly for several releases?

  got completely bogged down in the minutia back-and-forth

So, hence this post, which I am not even sure I should be writing, but which I hope will be useful

My goal here is to make participants of this discussion to reflect on their behavior. I don’t want to make anyone to change their behavior, but I hope that a bit of reflection can help to make future discussions better for everyone, it’s not a zero-sum game!

In particular, @stepancheg, @Pauan and @RustyYato got engaged into self-reinforcing “no, you are wrong” cycle which is the core of the issue here.

It’s interesting how this all started:

• Paupan answered with “it’s easy to write a macro yourself” to leaxoy’s comment above.

• stepancheg, thinking that this was response to their macro proposal, replied “but that doesn’t help at all with postponing syntax descision”

• Paupan, thinking that stepancheg replies to reply to leaxoy, disagrees with it:

  stepancheg: You didn’t get the point. A macro could be used to postpone syntax decision.

  Paupan: No, that was not their point.

  Curcialy, point refers to different things here!

• It all went downhill

I certantly can’t blaim neither stepancheg no Paupan for not understanding who replies to what. That’s really hard in on-line discurs! In fact, I myself realized that Paupan was replying to leaxoy only when writing this post.

However, there are tricks to make this less likely.

It’s useful to make crystal clear to whom you are replying, by quoting or @mentioning. If Paupans comment started with @leaxoy, I wondn’t be writing this text now

But a more powerful trick is to understand that you are actually arguing with another person (understanding is a hard bit here), stop the “arguging” and tell, in your own words, the other person’s position (i.e., what are you arguing against). Don’t refer to it as “the point”, spell it out like “I think your position is so and so, is that correct?”.

Another useful meta thing is realising that we argue because we find it pleasurable! Really, petty hating is pleasent (kudos to Andrey Breslav for this thought)! It’s important to realise this and understand, that, if you feel the urge of engaging into argument, that might be just because you want to say “you are wrong”, and not because you really want to make a point. Guilty as charged here! My previous comment was partially “someone’s wrong on the internet”, but I’ve thought that this particular example of strange macro was never brought up before, so I’ve decided that it’s valuable to make that comment.

I guess that’s all I want to say?

[Pauan]

@matklad

It’s useful to make crystal clear to whom you are replying, by quoting or @mentioning.

I would just like to point out that I did reply to leaxoy, but I've noticed that Discourse sometimes puts the "Reply to {user}" icon, and sometimes doesn't. I have no clue why it's inconsistent, it seems to be a bug. So it seems we can't rely upon that feature.

[RustyYato]

If you are the very next post when you reply to someone it doesn’t put the reply icon, otherwise it does. For example, this post will not have the reply icon.

[RustyYato]

But this one will.