Yet another async/await poll

I know everyone is tired from heated await syntax discussions, but nevertheless I would like to accumulate a more focused feedback regarding the team’s await proposal, compared to the earlier poll. Let’s keep in mind that results of this poll are not binding in any way and it’s just yet another way to collect feedback, but in a more organized fashion.

  • Continue with fut.await and think about generalization later
  • Introduce await fut first and add postfix variant later
  • I strongly dislike both options
  • I don’t have strong opinion

0 voters


There should be a “no strong opinion” option.


Yes, you are right. Those who voted earlier, please re-vote.

I think the question is not well-posed (the disjunction of all options is not a tautology):

  • The first answer implies that lack of generalization is a property present in and somewhat unique to fut.await
  • The second implies that one wants a postfix-variant later, not only await fut
  • Having a strong dislike of one answer but not the other has no representation
  • Not strongly disliking an option does not equate to continuing with that

Similar problems were a reason for me to participate in none of the poll that popped up


In this case, it’s a preference of which action to take, so strong dislike one way or the other is no different than a mild preference. (I agree that “add postfix variant later” and “think about generalization later” should potentially be “consider _ later”.)

I believe the poll to be fairly unbiased for what it’s trying to show: preference of the community between the two most likely supported options available to us currently that would resolve await syntax for the MVP stabilization.

The question is about what people think should be done to the specified deadline. I’ve selected await fut because in the post it’s implied that in future fut.await may become a simple application of “dot empowerment”, thus many have noted in the thread that it may be more logical to first introduce less controversial await fut and then work on postfix keyword(s) afterwards. I highly doubt that any other await proposal will have any viable chances in the upcoming team meting. Thus to keep poll more focused I haven’t included any other options.

If you strongly dislike both options, just vote so. If this option will get major votes, then it will be evident that community is not happy with neither fut.await nor await fut. But as we can see right now this option didn’t get much support.

Though a small clarification regarding options may be indeed in order:

  • If fut.await will be stabilized first, then it’s possible that no generalization will happen in future and await will be a sole postfix keyword.
  • If await fut will be stabilized, then it’s possible that postfix variant will be never implemented if practice will show, that prefix await is not too bad. And if there will be indeed a strong need for postfix await, then 3 options are possible: .await will be unique, other keywords will be usable in postifx fashion in addition to await, universal pipelining operator instead of extending dot meaning.

Later discussions in both cases can be conducted in a more relaxed manner without deadline pressure.

1 Like

Afaik, the syntax will chosen to the deadline but the two options aren't the only available. The poll question itself also doesn't state that its answers are to be chosen under that presumption (which I find reasonable but should be clear). In that case a better question to ask explicitely:

Having to choose one syntax until the deadline <I think 23 May>, to which of the options would you agree most:

That is a fair consideration, however it makes this a loaded question as it is mentioned nowhere. Not allowing an answer that disagrees with that sentiment makes it impossible to bring up the point that maybe another option should be considered for the meeting. Just in case, it may be useful to have an option of:

None of the above

It might be that one considers one of these syntax options nearly as good as another one not represented but the other much worse. None of the answers represents this option because it does not permit the perspective that another pair of options should be considered as top contenders instead.

I'm sorry if this comes across as too passionate but not having not any poll give me an option to vote on yet has me really question their usefulness to gauge the opinion across all of the community. The outcome of a poll is always: Among those who agree with any of the options, which is the most common. That's why it is useful to have the disjunction of all answer be a tautology or at least be equivalent to the explicit asumptions in the question.


In the questions “Think about generalization later” and “first and add Postfix variant later” both imply that some sort of generalization of Postfix chaining is a good thing.

I disagree.

I could live with either “await future” or “future.await” but in either case I would not want to see a generalization of Postfix chaining. Because I don’t want to see Rust embrace TIMTOWTDI.


We already have function syntax (prefix) and method syntax (postfix) which are 90% interchangable (the exceptions being free fn and method resolution). There’s already More Than One Way To Do some things.

Providing the tools for different styles of data manipulation is not wrong in and of itself.


It’s a fair criticism, though unfortunately it’s a bit late to change the poll. Hopefully future readers will read our discussion before voting.


As I wrote in the earlier message, implementing one variant does not mean the second will be 100% implemented as well, it will be left up to future discussions, after stabilization of one of the options has happened. Maybe I’ve used not the best wording, but hopefully it will not influence results too much.

1 Like

I'm not issuing a proposal to change any existing syntax. I'm just pointing out that the question phrasing above is extremely loaded and implicitly is forcing respondents to agree to a controversial new proposal that hasn't even had an RFC yet.


(I'm not going to partake in this poll or any other poll on await. I don't think they are useful, they are conducted in unscientific manners. They would certainly not be fit for academic papers but neither for fora requiring lesser standards either. Flaws include, but are not limited to: 1) No randomization of questions, 2) Biased formulations presuming the future, 3) Small selection of options -- and no ability to select multiple choices, 4) Not using a realistic setting to ask questions (e.g. no snippets and no syntax highlighting, 5) Questions are not done first in an environment where the user has already been loaded with opinions by others, 6) No ability for people to elaborate and give their reasoning after conducting the poll -- the last one being essential to have any value for me)

To remove any possibility of doubts as to what syntaxes I consider most appropriate, here are some syntaxes from most to least appropriate:

  1. fut.await?
  2. some sigil (e.g. fut#?)
  3. fut.await()?
  4. fut.await!()?
  5. fut await?
  6. (await fut)?
  7. await fut?
  8. await? fut

That is, assumptions that prefix await is considered viable by me is mistaken.


Realistically how will fut.await be generalized?

One of the reasons I like await fut despite wanting a postfix variant is it’s the most simple candidate and leaves things open for what the community can mostly agree on. Right now people seem very divided on using the dot operator for control flow that we see in fut.await


I’m not sure if I’d like generalization of .keyword or some other prefix-postifx keyword generalization. I never found myself in situation where I’d really need foo.match {}, and syntax like foo.return or true.if {} would be too weird.

I do think generalization of await!(foo) to foo.await!() would be nice. I had a need for a try!()-like macros that behave differently from ?. I’d love to have value.my_try!(). But it doesn’t seem that postfix macro is an option.

And to be honest, eventually I’d probably get tired of writing the extra !() after the await. The plain .await looks odd, but speaks to my laziness :wink:


Strongly agree with this, if accepting .await opens the door for the above other cases then I'm strongly against it.

Postfix macros do seem to have lots of other uses too.

This. And once your brain adjusts the code does look nice.

One case that occurs to me is something like

try { ... }.match { ... }

Otherwise, you end up with, somewhat awkwardly:

match try { ... } { ... }

Of course, if some kind of catch is added to the language, this becomes somewhat redundant.

I think the other angle to look at it is, instead of trying to figure out how .keyword could apply to existing keywords, instead consider that some future keyword operations might also benefit from postfix chaining.

1 Like

Of course this makes sense, however I feel that await is the wrong place to start this. It should be an RFC in its own right.

1 Like

What should be an RFC in its own right? That future language additions might choose to use .keyword syntax when appropriate? This is inherently something that has to start somewhere unless you’re aiming for fully generalized keyword operation chaining as syntax sugar for existing leading keywords.

1 Like

Pretty much this yes, open the door formally for a change to the language regarding field access to allow for .keyword, starting with await.

This isn’t field access, so there is no language change being proposed affecting field access. Field access is .identifier when not followed by (argument list). This is .keyword. I understand that some people are concerned that beginners unfamiliar with a particular keyword might mistake it for an identifier, but that doesn’t change the fact that it’s an entirely independent syntactic construction. Pretending otherwise seems more likely to invite the very confusion people are seeking to prevent.

The use of .keyword in the particular context of .await has already been amply considered. async/await can’t be stabilized without resolving the syntax question. There really is no reason to try to legislate under a new RFC whether a particular design choice that has already been considered as part of an existing RFC should be permitted unless the goal is simply to impede the adoption of that design choice.