Make `async` and `closure` keywords, making them syntactic sugar like `func`

[haoyu234]

Abstract

Make them a keyword, which can automatically help users add corresponding pragmas, just like func does.

Motivation

In this RFC, it is a sweet syntax sugar, and in the future, it may become a new function type, just like converter and iterator.

When writing asynchronous code, we always type {.async.} over and over again. I wonder if it can reduce our typing burden if it becomes a syntax sugar.
nim uses indentation to express the structural hierarchy of control flow, which reduces many curly braces. If async and closure become keywords, the use of curly braces will be further reduced. I wonder if it can make the code more refreshing.

Description

In simple terms, the async keyword automatically adds {.async.}, and the closure keyword automatically adds {.closure.}.

Since async is not built-in in nim language, when the user uses this keyword, the compiler should search for async symbol in the current namespace. If it is not found, the compiler should terminate the compilation and give an error message.

In nim2.0, we have For loop macro, maybe, in the process of implementing async keyword, we can also have Async macro.

macro async(stmt: AsyncProc) =
  result = newTree(nnkAsyncProc)    # Create a new Async proc.

Code Examples

# This is an asynchronous function
async doStuff(): int =
  discard

# This is a closure function
closure doStuff(): int =
  discard

# This is an asynchronous function pointer
let funptr: async (): int

# This is an closure function pointer
let closureptr: closure (): int

Backwards Compatibility

The async macro of the third-party library chronos can pass parameters. When async becomes a keyword, it seems that there is no way to pass parameters

[arnetheduck]

import chronos

async:
  proc f(): Future[int] =
    10
  proc g(): Future[int] =
    await f()

echo waitFor g()

this works today, fwiw

[haoyu234]

This is a solution provided by discord user fabricio, which I found very interesting.

asyncDef doStuff() -> int:
  echo 1
  echo 2

Looks a lot like Python code.

[almorgansbcc]

Is {.push async.} useful?

[xTrayambak]

Is {.push async.} useful?

This. Use the {.push.} and {.pop.} pragmas, it seems like the best and cleanest solution to me.

[nitely]

async keyword would really help with the way I'm implementing exception tracking nim-lang/Nim#24582 I believe.

[arnetheduck]

async keyword

for the chronos version of raises tracking, what would have helped rather than an async keyword would have been the compiler exposing more type arithmetic utilities, as well as co/contravariance - with those two features, it would be easier both to provide correct "normalization" of raises lists and better backwards compatibility / "looser" definitions for example when making callbacks and for example assigning to async proc types - this is somewhat tied to maintaining the raises list as a generic parameter - it makes the future assignment-incompatible for anything but the most trivial cases - these language features would reduce the surface area of that incompatibility.