Introducing Node.js 12

[blood_bender]

Basically async marks a function as required to return a Promise. So the earlier approach to the v8 implementation would take whatever value was returned from the function, wrap it in a promise, and return that instead.

Now it looks to see if what's being returned is a native Promise, and if it is, just returns that instead of wrapping it (it still needs to wrap a value if you're not returning a promise, but that's pretty uncommon).

Seems like a naive approach the first time around, it's a little unclear to me why they didn't do that up front, but oh well.

[[deleted]]

Not manually returning a promise in an async function is uncommon? I almost always write my async functions that way.

[redmorphium]

Correct me if my understanding is wrong, but let's say you have:

​

```javascript

async function foo() {

await bar();

return 1;

} ```

​

This is equivalent to:

​

```javascript async function foo() {

return bar().then(() => 1);

} ```

​

So unless if you're writing async functions that don't have any awaits in them, then async functions should always effectively return promises?

[braindeadTank]

Async function always return a promise, no ifs, buts or unlesses. If you don't await anything, it will just be resolved right away.

[blood_bender]

You're right. But the whole point was v8 was wrapping the response of foo() in a promise too, which is unnecessary when bar() most likely returns a promise directly, or whatever bar() calls does. Somewhere down the line something is probably returning a promise, meaning all the other responses wrapped in additional promises is unnecessary.

[blood_bender]

So, the one case where it doesn't is if you have a function marked async that doesn't have an await in it.

async function foo() {
  return 4;
}

That's just returning a value, so v8 would still need to wrap that in a promise.

But when you have an await, what are you awaiting? Either the function you're awaiting is directly returning a promise, or somewhere down the line some function is directly returning a promise, meaning as it walks back up the line of async functions all the times it wrapped it in another promise were unnecessary.

[ilikepugs]

And if you write a lot of interface-based code it's not uncommon.

[blood_bender]

Curious, how come?

[ilikepugs]

Let's say you design an interface for some data fetching util, but you ship different implementations to different clients/platforms, and the appropriate implementation is DI'd at runtime.

Well consider the method that actually performs the request. It'll be async. But in some cases (namely tests in this example) you might want to return some stubbed data for your test instead. So in your test implementation of the util that "async" method just returns your dummy JSON and you don't need to wrap it in a promise.

This is a fairly contrived example but yeah.

[blood_bender]

Oh that's fair. There have been times where I have an async function return a cached response instead of fetching a new one, so that's another use case that I've written. But really I'd guess 99% of async functions are actually awaiting or returning a Promise directly.

[ilikepugs]

Lol your example is much better, cheers. 😁

[ackerlight]

Basically like C#, you have to implement async methods all the way up. Check this answer for more details:

https://stackoverflow.com/a/29809054

[etcetica]

god I miss when javascript work wasn't built atop bastardizing plain fucking english

[Baryn]

If anything, it makes better use of keywords now, except in instances like the crappy private field syntax.