Depends how you look at it. The straightforward answer would be "no" because await lets you assign the result of a promise to a variable without calling `.then(...)` with a callback and then accessing the variable inside the callback (where the callback would be the closure). In that way of thinking, async/await directly let us write code with less closures.

Note that that explanation was purposefully ignoring any implementation details about whether or not closures are actually being created/allocated and was purely focusing on whether the programmer had to type out/read closures as extra syntax.

Actually, functional programmers might point out that even without async/await, assignment in imperative languages is still just some syntactic sugar for actually using closures. That is, in functional languages, its almost never idiomatic to directly "assign" to a variable (that is, overwriting the variable's previous value); instead values are "bound" to variables in let statements (or whatever the language's idiomatic equivalent is)--and let statements are effectively syntactic sugar for function calls/closures.

If you're familiar with haskell: you can think of imperative code as haskell's do notation but with the Identity macro (aka no special mode of computation, just the results of each function flowing into the next with "assignment" converted into functions). Marking a function as async (and thus allowing you use to await inside it) is just switching that function to be under the Promise monad. (but be careful! JavaScript promises aren't strictly monadic in that they auto-resolve if nested... so you can't have "Promise Promise a")

(... Sorry, this ended up being a bit of a mess of a braindump because you specified "implicit" closures :) )

It's explicit, since the `async` keyword must only precede a function declaration.

i.e.:

    async function () { ... }
    
    // or 
    
    async () => { ... }