Closed martinheidegger closed 2 weeks ago
Yeah it's possible to elide the outer await
.
I was on the fence over this. The await
made implementing this feature trivial while also making it consistent with where the await point will be. So having that await
increases consistency but technically isn't needed. Seems like it might be worth removing.
Another benefit of defer await
is that it makes it immediately clear that this is an async defer regardless of the contents of the block. That alone could be worth it given that blocks are presumably the uncommon case.
The outer function is already "async" and as such, to me, it is already clear as it is.
To add another minus point for defer await {
which is merge commit statements, say you have following code:
async function foo () {
defer {
releaseA()
releaseB()
}
}
and one of the resource upgrades to async
like this:
defer await {
releaseA()
await releaseB()
}
... then we have two changed lines where else only one would be necessary. Also: If only the second line changes to "await" then there would need to be a compile/runtime error that is annoying to deal with.
Okay I'll see about making it work without the await
. It does seem out of place if you were to think of defer
like a floating finally
block e.g. finally await { ... }
I've removed the defer await { ... }
syntax. It's definitely more work for transpilers, however, that shouldn't be problematic if I provide a reference implementation. Engines should be able to handle it as well although there could be push back from the extra effort. I might try to add it to v8 just to see how hard it'd be. Thanks for calling this out!
as the operations in a block can have an await property usable it seems like the addition of an "await" in blocks is overzealous.
and it could just as well look like: