A final proposal for await syntax

[BatmanAoD]

I don't think the total number of comments is quite fair as a metric for how much "noise" is being generated without new arguments, because a lot of the comments are clearly not written with the intent of changing the team's mind.

I do, however, think that several points made so far seem fairly novel. I'll quote them here without introducing my opinions on whether they're valid or important; they're merely included because they weren't mentioned in the team's write-up or in the previous internals thread.

.await makes + non-commutative in some cases:

@mgeisler

let foo = some_expression.await;
let bar = other_expression.await;
return foo + bar;

....there is now an observable difference between the above program and this program:

let bar = other_expression.await;
let foo = some_expression.await;
return foo + bar;

.await() should not be dismissed as "not a method":

@zackw

“no, really, await is a method ” (and therefore postfix .await() is the most logical choice)

There is some circumstantial evidence that the community may feel strongly against this proposal, which may warrant additional outreach and research:

@tkaitchuck

There is a large divergence between where the Lang team ended up and what a poll of readers of this form preferred.

@whitfin

I think it’s worth polling the entire community on whether the plan should even change at all. The familiarity of await foo() should not be ignored, and I imagine a lot of people don’t care enough about (await foo())? to not have that familiarity.

Chaining may actually be detrimental to clarity:

@devsnek

Something that other languages have done is to purposely split up suspend points so that it is immediately clear to the reader and writer what the control flow of the code is.

.await may be detrimental to accessibility:

@phaylon

I don’t have a source for this, but I’d assume an additional prefix option can have advantages for screen reader usage as well? Then you go into the expression knowing there’s an await point.

There is a proposal for a generalized "postfix (or infix) keyword" syntax that would not apply to .await:

@BatmanAoD

@lordan

FWIW, if we consider the block as the first “argument”, and the expression/condition as integral to the keyword syntax, then it could also be a more Python-ish:

{ ... }.if expr else { ... }

{ ... }.while expr { ... }.loop { ... }.for var in expr

To bring this tangent back to await , this looks like a good demonstration that “postfix keywords” are not a clearly defined concept with a single definite syntax/semantics, and in particular, it’s not clear how postfix await would fit into this scheme.

An argument for .await that wasn't in the write-up:

@BrianMWest

postfix is best...[because] this is direction of eye movement to read an expression.