Make top-level scope as async context

[cometkim]

to support top-level await

[cristianoc]

Async functions can be called at top level.
Not sure if there's a compelling use for await at toplevel.

[cometkim]

I just wrote bindings to tinybench, which is a library for benchmarking

https://github.com/cometkim/rescript-tinybench

Not sure if there's a compelling use for await at toplevel.

Following example

let run = async () => {
  await bench.run(.)

  open Belt
  bench.tasks->Array.forEach(task => {
    switch task {
    | {name, result: Some(result)} => {
        Js.log(`Task name: ${name}`)
        Js.log(`Average Time (ps): ${Float.toString(result.mean *. 1000.)}`)
        Js.log(`Variance (ps): ${Float.toString(result.variance *. 1000.)}`)
        Js.log("")
      }

    | {name} => Js.log(`Error occured while running bench ${name}`)
    }
  })
}

run()->ignore

could be just

await bench.run(.)

bench.tasks->Array.forEach(task => {
  switch task {
  | {name, result: Some(result)} => {
      Js.log(`Task name: ${name}`)
      Js.log(`Average Time (ps): ${Float.toString(result.mean *. 1000.)}`)
      Js.log(`Variance (ps): ${Float.toString(result.variance *. 1000.)}`)
      Js.log("")
    }

  | {name} => Js.log(`Error occured while running bench ${name}`)
  }
})

I'm using top-level await in most of my server projects, and this makes a significant difference in the application execution context. for example this case

[cristianoc]

@cometkim one could try to

1. turn off the check for where await is allowed, so it's allowed everywhere, and see that examples compile fine;
2. then, turn the check back on and allow specifically top-level bindings presumably of the form let x = await ....

[cristianoc]

@cometkim take a look at #5940, with some examples.
I believe supporting toplevel await means that await can appear anywhere unless it's under a non-async function.

[cometkim]

Yep, that's correct. but top-level await is available only on module context, which means ESM, not CJS

Maybe it should be depend on module-specs in bsconfig.json

[cristianoc]

Yep, that's correct. but top-level await is available only on module context, which means ESM, not CJS

Maybe it should be depend on module-specs in bsconfig.json

Not sure we want to add extra complexity to the language for this. It should be easy enough for the user to figure out that toplevel await does not work in CJS.

[zth]

I agree - not worth the extra complexity. Accidentally using it in cjs will crash early, so it should be easy to discover. Most bundlers, if you use one of those, will probably reject it too I guess.