Async / Await syntax straw poll

[tkaitchuck]

The Syntax discussion thread seems to have been overwhelmed with comments. So I created a form to allow everyone to register their approval or lack there of to various existing alternatives without having to spam the thread.

I will aggregate the submissions and post the results here. Please note that this is to gather feedback only. This is not a vote.

Please do not discuss either the feature itself or the syntaxes on this thread. If you have additional comments on one of the options here that have not been addressed or wish to propose another option please do that on the Syntax discussion thread. Any option mentioned there will be added to the survey.

So please submit your thoughts here. Note: it does require logging into a Google account, but collecting addresses is disabled so it is anonymous if you don’t provide your username.

If after reading the discussion, you change your mind, just click the link again and you can edit your responses.

[upsuper]

For the “Postfix Space syntax”, why couldn’t we do

let result = future await;
let result = future await?;
let result = future await.foo();

?

It is already mentioned in the discussion thread: Await Syntax Discussion Summary

[tkaitchuck]

Yes. Sorry. Fixed.

[elahn]

Thanks, @tkaitchuck. I think naming them “Field access syntax” and “Field! access syntax” is misleading or at best a “leading question” which may cause people to form views they otherwise wouldn’t have.

I suggest “postfix .keyword” and “postfix .macro! without empty parentheses.”

[jethrogb]

I started filling this out, but I think filling in the form is quite cumbersome for a “straw poll”

[comex]

Yeah, it’s somewhat odd that you have to explain your reason for disliking a syntax but not for liking it.

[tkaitchuck]

I added a “Looks bad” option. Feel free to update your response if you like.

[vi0]

Maybe reduce to only one variant with just postfix sigil instead of splitting it for @ and #, stating that concrete character is just an example?

There may be separate question “Which sigil character do you prefer for await?”, with “Other” input field.

[tkaitchuck]

@vi0

Maybe reduce to only one variant with just postfix sigil instead of splitting it for @ and #, stating that concrete character is just an example?

I deliberately made all of the options independent so that they wouldn't compete with one another and people could like multiple things.

Looking at results so far, a lot of people don't see # and @ as interchangeable. # seems to be getting a lot more support, and most people that are ok with @ are also ok with # but the reverse does not appear to be the case.

This is still early though, so things could change.

[AGausmann]

I posted some feedback on the main thread and then saw this here. Here’s a copy:

It’s incredibly difficult to assign a binary yes/no to each available option. Some I strongly like, some I think would be okay, some I don’t prefer, and some I don’t think fit at all. Might want to check out resources on rating scale questions when you make surveys like this, and maybe consider revising this one? In general, the minimum should be 5 different rating choices (think 5 stars on reviews). Some more scientific ones may even use 7.

[tkaitchuck]

UPDATE: This is outdated, see below, but left for posterity

Current standings. (The poll is still open)

From most to least approved:

Macro style syntax: 68.1% approve 31.8% favorite 2.3% it’s complicated 29.6 dislike

Postfix macro style syntax: 59% approve
38.6% favorite 2.2% it’s complicated 38.8 dislike

Keyword: 56.3% approve
24.7% favorite 1% it’s complicated 42.7% dislike

# Sigil: 42.7% approve 28.1% favorite 57.3% dislike

Function style syntax: 40.4% approve 11.4% favorite 59.6% dislike

Method call style syntax: 38.6% approve 18.2% favorite 61.4% dislike

Field! access style syntax: 38.6% approve 12.6% favorite 61.4% dislike

@ Sigil: 38.2% approve 18% favorite 61.8% dislike

Keyword with braces: 38.2% approve 9% favorite 61.8% dislike

Keyword with optional parentheses: 37.5% approve 12.4% favorite 62.5% dislike

Postfix space syntax: 32.6% approve 14.6% favorite 67.4% dislike

keyword with ? special case: 30.7% approve 12.4% favorite 69.3% dislike

Field access style syntax: 25% approve 9.1% favorite 75% dislike

Sigil + await suffix: 22.5% approve 2% favorite 77.5% dislike

Keyword with additional try keyword: 21.3 % approve no favorites 78.7% dislike

Observations:

• There is no clear consensus.
• Both macro style syntax options seem to be doing very well.
• People don’t seem to be simply divided into prefix and postfix camps, as @withoutboats suspected.
• The high levels of approval for Macro style syntax and the simple Keyword solution may indicate the “order of operations” problem indicated in the summary document may not be as bad as the solutions.
• All proposals that modify the Keyword solution to improve some aspect of it have fewer people who approve and fewer who consider it their favorite.

[elahn]

The numbers for macro syntax baffle me; let’s clarify them. Team members have stated they want to choose the ultimate syntax now. They’re not going to stabilise macro syntax then replace it later.

This is real code from fuschia via the await-syntax repo:

let response = await!(wlan_svc.list_phys()).context("error getting response")?;

opts::ClientCmd::Disconnect { iface_id } => {
    let sme = await!(get_client_sme(wlan_svc, iface_id))?;
    await!(sme.disconnect())
        .map_err(|e| format_err!("error sending disconnect request: {}", e))
}

It creates unnecessary temporaries, takes more time and mental effort to understand the control flow than a postfix syntax, such as:

let response = wlan_svc.list_phys()#.context(“error getting response”)?;

opts::ClientCmd::Disconnect { iface_id } => {
    get_client_sme(wlan_svc, iface_id)#?
        .disconnect()#
        .map_err(|e| format_err!(“error sending disconnect request: {}”, e))
}

Do you really want await!() macro syntax for all time?

• Yes, macro syntax is my ultimate desire
• No, not if we can’t change it later

[eaglgenes101]

@elahn

Do you really want await!() macro syntax for all time?

That's an overly dichotomous way of looking at the issue. As far as I'm aware, there's no reason why the await keyword couldn't be weakened (joining other weak keywords such as union) so that await! is treated as a perfectly good macro invocation rather than an unrecognized keyword-punctuation mark sequence. It'd stick out sorely in the syntax, sure, but it could be done.

Of the options for await syntax, prefix with mandatory delimiters looks almost the same as the syntax is it now (aka the macro), while neatly sidestepping this technical issue. I would be surprised to find out about individuals that like the current syntax the best that don't at least consider this the next best alternative.

[CAD97]

Even if we unreserved await it can’t be a “normal” macro due to the fact it uses generators for the transformation, and the error messages need to treat it as a unit, rather than as a yield loop. The possibilities are that await is a macro-like production, or that it’s a macro that expands to an unwritiable syntax node for what await would be if it weren’t a macro.

[Uther]

Maybe it can be done. But the @elahn question was the right one. We were asked about the final syntax we want. If you mix the responses of the ones who think await!() can be a temporary measure with the one that think it is a good idea for the final syntax, the straw poll is biased. You can’t fairly compare the results of await!() with the other proposals.

Having the await macro as a temporary measure is an interesting but orthogonal problem. That should be discussed separately. By the way I’m really not sure the language team would like to go this way since it would be quite a burden. If the macro style is released on stable, it will have to stay in the compiler forever since Rust commit on stability. The transition from try!() to ? was hard and it was a regular macro. A transition for the await syntax would probably be even worse.

[H2CO3]

@Uther

The try to question mark transition was hard

How/why exactly was it hard? AFAICT it was not the least bit. An operator was defined with a superset of the semantics of try!() (which, being a superset, was just the same initially), then it got stabilized, then people learnt to write new code with ? instead of try! and hopefully they gradually rewrote / are rewriting old code. Of course discussion happened around ?, but not because it wasn't there from the beginning.

There's not much burden in "supporting" the try! macro either: it's simply not changed and… pretty much that's it. It still works and there's no reason why it would break out of the blue.

[CAD97]

Do you not remember the large number of voices complaining about the switch that continued to use try! until edition 2018 forcibly removed access to it by making try a keyword? The transition wasn’t free. There was, at a minimum, social difficulty in moving from the working try! macro to the ? operator.

The try macro does add complexity to the standard library, especially since it required the addition of raw identifiers to stick around in the new edition.

Even if maintenance is “free” (let it be), it’s still weight on the eventual language specification if it cannot be a pure library solution (which as a keyword macro-like construct rather than a real macro, it cannot be).

[H2CO3]

I do, you are right in that regard. Not like they had a realistic chance… New syntax, and new features in general, once stabilized, as well as new idioms, are pretty much being forced down the throat of users. You could make that argument about many features. We could cite pattern binding modes / match ergonomics. Lots of people (me included) complained and asked for at least a clippy lint – nothing happened. It was IMO an even more radical change in semantics than transitioning from a macro to an operator.

[StyMaar]

Funnily enough, I created my own survey on Tuesday that I posted only on Reddit (I didn't have an account on this forum before just five minutes ago).

And the results are :

I'd be curious to see how different are the results, with different wording (mine is especially curious about the potential outrage that would result from the adoption of one syntax or another, hence the wording) and different demographic target.

Edit: graph legend

Light blue= Perfect

Dark blue= Not optimal but Ok

Light green = not really good

Red = I hate it

Other colors = variation on the «I hate it» answer.

[tkaitchuck]

Those agree quite well with the results of the poll above. Can you clearly some of the names above? (“Magic” way or “obvious” way for example)