One final syntactic bikeshed...

[allenwb]

I know it is quite late for this, but I find no record of this every having been suggested or discussed.

Why not use the syntax:

for (let n await exper) ...

This seems much more aligned with the other forms of the for statement and it emphasizes exactly where the awaitng takes places.

[domenic]

Huh, we discussed various alternate forms (see #11 and #24) but never one that removed the of.

I'm not a big fan of removing the of myself as now this feels like it's on a level playing field with for-in and for-of (i.e. it's a third type of iteration), instead of being part of the "for-of family". I realize this isn't a super-strong argument.

However, I don't understand your idea that this emphasizes where the awaiting takes place. To me it looks like you are awaiting exper. But you are definitely not; you are awaiting each iteration.

[ebraminio]

This looks better than "for await () { }" IMHO, this looks more "Java"Ish also.

What is the relation of this proposal and "for ( on )" on here? That also went for removing "of" so this might be also reasonable?

[domenic]

for-on has been withdrawn, as seen from the bold warning on the page you link to.

[allenwb]

The binding (or assignment) of the loop variable takes reoccurs on each iteration. To me, the placement of await after the binding/assignment target emphasizes that while for await is suggestive of a single await for completion of the entire for loop.

Alternatively, you might say await of to emphasize that the state will "await" for each "of-like" iterative value. But that is getting wordy. In the context of a for it seems reasonable to understand await as meaning await of.

[zenparsing]

Let's say you want an await expression as the async-iterable:

// for-await-of 1
for await (let n of await exp) {}

// for-await
for (let n await await exp) {}

// for-await-of 2
for (let n await of await exp) {}

[Jamesernator]

I'm pretty happy with the current syntax myself, it's intuitive enough with the existing for-of and is easy to spot at a glance that's its a async loop not a sync one thanks to the await placement.

[ljharb]

One possibility to avoid the confusion about await that @allenwb mentions above, is for async - is there a reason that wouldn't work?

[domenic]

See previous threads linked above.

[domenic]

I think it's best we close this. No arguments for new syntax (or previously-suggested syntax) have been convincing; in particular #106 (comment) seems fatal.

Indeed, I can't see a way to really use await that represents what's "actually" going on, as none of the values (n or exper in the OP) are the promises that will be awaited. So the best we can get is putting it somewhere that heuristically conveys what's happening, and IMO the current spec's syntax conveys "a for-of loop that involves some awaiting" pretty well. Furthermore, it hasn't caused much confusion, at least once people get past the idea that it's await instead of async.

In any case, thanks for the suggestion!