Await postfix operator(@)

💡 Ideas
4

@aclaymore's referenced proposal would directly solve this issue, and it would be nice to see something like that added. As for what can be done today, I've started making it a habit to just use .then() instead of parentheses whenever I need to nest awaits. It generally makes the result a little cleaner.

Some examples:

// before
await (await fetch('https://example.com')).text()

// after
await fetch('https://example.com').then(x => x.text())

// before
await (await (await (await asyncCalculator.plusAsync(1)).minusAsync(2)).multiplyAsync(3)).divideAsync(4);

// after
await asyncCalculator.plusAsync(1)
  .then(x => x.minusAsync(2))
  .then(x => x.multiplyAsync(3))
  .then(x => x.divideAsync(4))

Also, for this point:

To protect our fingers and keyboard

In general, it's better to optimize for readability over writability, as code is read much more often than it is written. So, while this argument is still a valid one, it's generally put really low on the list of priorities. It's often overshadowed by things like: how readable is this new operator over the old one? (which, I'd argue if we're not nesting, the await operator is more readable, but that's really a matter of taste). Do we really need to use one of our few precious ascii symbols for this? If we introduce too many operators like this, will JavaScript just turn into an ascii soup that's difficult to understand? etc.

Edit: Just saw @mhofman's comment. Nested awaits have always been a bit of a pain point for me. When I started using the .then() trick, it helped out a lot. I didn't think about how pipelines would fix this, but yeah, I guess that would help fix the issue a lot - to the point where I wouldn't really feel a desire for this sort of feature anymore. But, I guess pipelines aren't that much different from just using .then() as well, which might be why I found that to be so helpful.

1 Like