allow await

[Clément P]

Expression = first:[0-9]+ [+] last[0-9]+ { 
  return await asyncAdd(first, last)
}

get this error :

await is only valid in async functions and the top level bodies of modules

await could be allowed inside expression body function.

[Joe Hildebrand]

I thought I needed this once or twice, but have gotten around it by pre-processing the async class, post-processing a generated AST, or parsing once, processing, and parsing again. The most interesting cases are those where the text the grammar would accept is modified by the results of an async call that uses information parsed from the input.

There will have to be an option that affects code generation.

Discussion:

• I assume this is going to have a pretty big negative impact on performance, but let's measure it.
• Does every parse function get marked as async? I don't see any good way around it, since an otherwise-sync rule might call an async one.
• Determining if a rule should be run in an async context would be difficult without a full parse of the code in result and predicate blocks, or a mechanism for the async flag to a rule's metadata
• Tree shaking rules that were determined to be async might help, but that's likely to run into edge cases, and the top-level rule will always be async, which means the gains are likely to be minimal.
• There will need to be a separate set of TypeScript types for async grammars, particularly in #477
• Initializers and top-level initializers should be run in async contexts as well.

This is going to be a good amount of work to get correct. A compelling use case would help increase its priority.