Async / Await syntax straw poll

language design
61

It does, over (await e)?.

62

You are just wrong.

expr =
  | "await" expr
  | expr "?"
  | IDENT // Make our grammar terminating.
  | "(" expr ")"
  ;

vs.

expr =
  | expr "?"
  | expr "." "await"
  | IDENT
  ;

If we want to nitpick, the first grammar requires one more alternative (parenthesis) to express as much as the second one.

63

I didn’t say that adding both await and await? makes the grammar simpler. It doesn’t, as syntactic sugar never does. But it does provide the semantic compression you mentioned while arguing for e? and the others.

And Rust already has brackets and fields, so counting the productions in a subset of the grammar doesn’t prove anything.

1 Like
64

I thought you meant that (await e)? (without await? e) requires fewer syntactic forms than e.await? (not true).

65

Just new to this discussion, has a “.” + some sigil been mentioned already? For example:

let result = future.!await?;
let result = future.@await?;
let result = future.#await?;

extended to match syntax it will be like:

try {...}.@match {...}
1 Like
66

What do you like about the second sigil? It's syntactically unnecessary, but does it have some other advantage?

67

What do you like about the second sigil? It’s syntactically unnecessary, but does it have some other advantage?

It just makes mentally and visually much easier to distinguish field access from await, because no field name starts with a sigil. And consider reviewing a diff patch, we don't/can't have syntax highlighting from IDE to help.

68

For this version of await I'd suggest to add a space before and after:

let a = get_result_of_future() await ?;
let a = get_result_of_future() await .or_else(|_e| Ok(...))?;
let a = get_result_of_future() await + 7;
1 Like
69

I get what you’re saying, but it still feels weird. At that point you might as well do something like:

let a = get_future().(await)?;
let a = get_future().(await).or_else(|_e| Ok(...))?;
let a = get_future().(await) + 7;

It seems unnecessary to me to replace .await with either of these. I don’t see the benefit as being particularly compelling. This might work for postfix function call syntax, though…

70

Final Results

The polls is now closed. You can see the results by clicking the link.

Summary: There have been no substantive percentage changes since my last update. As almost all of the votes were in at that point.

The final approval rank order was:

  1. Macro style - await!(future)
  2. Keyword Prefix - await future
  3. Method call style - future.await()
  4. Function call style - await(future)
  5. All the variation on keyword style (parenthesis, braces, tight binding, ?) in that order.
  6. Field access style - future.await
  7. Field! access style - future.await!
  8. Sigils @ followed by #.

When ranking by favorites it is almost the same except that Keyword (prefix) style comes in first. (by a fairly wide margin).

Observations

  • People do not want a new sigil. This initially was quite popular with early voters but dropped off rapidly with later voters.
  • The prefix style options: Prefix keyword or Macro style are strongly preferred to the postfix style that was supposed to improve upon them. This is reflected in both favorites as well as approval / disapproval percentages.
  • The extensions to the keyword syntax to attempt to improve it, such as adding a try keyword are much less popular than simply leaving the keyword alone.
  • The future.await syntax proposed by the lang team is very widely disapproved of. It’s approval percentage has not changed since it was announced as the proposed syntax. It has remained around 75% disapproval since the poll opened.

As noted before. This is not a vote and may well have no effect on the overall outcome. But is here to provide useful feedback to the developers.

5 Likes
71

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.