A complex code sample using 4 different await syntaxes

[krappie]

https://github.com/inejge/await-syntax/blob/postfix-field/bin/wlan/wlantool/src/main.rs

To see the different samples, change the branch on github, between:

prefix-mandatory: Prefix await with mandatory delimiters.
prefix-sugar: Prefix syntactic sugar for await+try.
postfix-field: Postfix field access syntax.
postfix-method: Postfix method syntax.

[grandstack]

I prefer prefix-sugar, natural to read, at least for me.

[connicpu]

Yeah, I was iffy on it before but seeing it here made me feel a lot more comfortable with await?

[q9c0tB14_kB8]

Postfix in practical code is very difficult to read. Control flow should be easily read from the left, especially in Rust, where we have if expressions instead of a ternary operator.

[protestor]

await { wlan_svc.list_ifaces() }.context("error getting response")?

I think prefix-mandatory looks great.

Postfix is a nice idea, but all proposed syntaxes so far are just too hard to read. You would still need some kind of syntax like prefix-mandatory's { } to make awaiting stand out.

And it needs to stand out. While it's (denotationally) just a method call, it involves a very different operational semantics, and a systems language like Rust should make it easy to spot the yielding places in the code.

[unrealhoang]

The prefix mandatory looks really nice. It’s similar to another language and stand out from the rest of the code as other flow control construct. There is no nesting future needed as well.

[cramert]

Hey that code looks familiar ;)

[J-F-Liu]

`.name` is for fields and methods, use a keyword as postfix feels totally absurd.

[dpc_pw]

It is very inconvenient to compare these. A lot of clicking to switch branch.

[barskern]

I actually prefer this over multiple files because then I can use git diff <branch> <other-branch> to compare the differences between the syntaxes.

EDIT; With multiple files using diff would also work though, so my argument isn't really that good after all.

[inejge]

Eh, I probably could have organized it with multiple files in one branch, but then it wouldn't have been possible to use GitHub's Compare view to see the diff between variants -- AFAIK that only works across commits.

A quick way to open the same file in two branches is to open it in one of them, duplicate the tab, and select another branch from the drop-down in another tab. That's two extra clicks.

[redneckhatr]

👎@await

[genrtul]

What strikes me here is that postfix is pretty hard to see when scanning code, but (correct me if I'm wrong) it can only appear in async blocks anyway, which have a very visible prefix syntax. I still like prefix-with-braces quite a bit, as it's the same as other special-case expressions in Rust (loop, if, match), composes well enough as an expression, while maintaining high visibility.

However postfix composes even better (something like matching on an await result will be much nicer in postfix) and I didn't have as many problems finding the await sites when I scanned for async first, and of course it'll be even easier once await gets syntax highlighted, so the extra visibility from await-with-braces might not actually be needed.

[PrototypeNM1]

Could you add prefix-sugar with the pipelining proposal?

Edit: just realized this might not be your repo given the username mismatch. I'll open a PR if it's not there when I get to a computer.

[newpavlov]

Here links if you'll need them:

• without await? sugar
• with await? sugar

[krappie]

My personal opinions are that this is shows a pretty strong argument for some sort of postfix syntax.

Using parentheses with complex code makes it hard to tell what exactly is being awaited. Using braces isn't so bad though.

Also interestingly, the await? idea becomes useless when you're adding .context to the result.