CS2 Discussion: Features: async/await

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10
Originally created by @rattrayalex on Sat, 23 Jul 2016 02:54:17 GMT

---

The syntax here could be quite tricky, and the feature is pretty important. This could be an opportunity for CoffeeScript to offer dramatically nicer syntax than ES6 for a core feature.

Let's discuss anything related to async/await here.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @DomVinyard on Mon, 25 Jul 2016 08:51:19 GMT

---

Implicit async if await is detected in the method body +1

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @carlmathisen on Mon, 25 Jul 2016 18:34:22 GMT

---

Agree with @DomVinyard on this one. This is what IcedCoffeeScript is doing.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @octet-stream on Fri, 29 Jul 2016 22:51:51 GMT

---

Why can't we just use syntax with async and await keywords? Anybody, please, explain the reason.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Tue, 26 Jul 2016 03:21:03 GMT

---

Ah, <= would clash with "less than or equal to" so that probably would not work.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @DomVinyard on Tue, 26 Jul 2016 08:32:03 GMT

---

@rattrayalex i think if we were trying to mess with 'await' as a keyword, the only sensible 'true coffeescript' approach would be to go the other way and make it the more verbose 'wait for', rather than trying to get people to memorise a new operator.

fn() ->
  res = wait for fetch('url')
  console.log wait for res.json()

But that has a whole bunch of issues, not least of all the overloading on the word 'for'. Personally think should be left untouched.

fn() ->
  res = await fetch('url')
  console.log await res.json()

Is such a wonderful reminder of how far JS has come, isn't it.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Tue, 26 Jul 2016 03:19:24 GMT

---

Personally, I find the await syntax a bit wordy for CS:

fn() ->
  res = await fetch('url')
  await res.json()

What about something like this instead:

fn() -> 
  res <= fetch('url')
  <- res.json()

Where <= compiles to = await and <- compiles to await. Of course, could make sense to just choose one or the other (probably <-, which is what Haskell uses) for both cases and infer.

Thoughts?

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Tue, 26 Jul 2016 03:17:21 GMT

---

Basic support is shipping in several browsers: tc39/proposal-async-await#97 (comment)

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Sat, 30 Jul 2016 18:21:29 GMT

---

@octet-stream why does async need an alias? (see my post just above, and others on this thread)

Note also this would prevent async => functionality, which would be very nice to have.

Slightly OT, but I also believe the do is unnecessary; in koa 2, next is a function, so it should just be <~ next().

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Tue, 26 Jul 2016 03:06:10 GMT

---

async functions don't necessarily contain await, eg;

async function () {
  return Promise.resolve(1)
}

... but, they also don't need the async keyword.

So I think I support implicit async as well.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Tue, 26 Jul 2016 17:38:09 GMT

---

I am leaning in the direction of leaving await as-is as well. At least for v1. Would be relatively easy to add an optional <- operator later if people want it (I'm hoping async/await experiences really big adoption).

In a world with a <- operator, I assume it would be better to allow both <- and await, rather than enforcing only the former, correct? eg; coffeescript allows both == and is

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @DomVinyard on Wed, 27 Jul 2016 08:17:47 GMT

---

@rattrayalex

I'm hoping async/await experiences really big adoption

amen, brother. and

it would be better to allow both <- and await, rather than enforcing only the former

Yeah, absolutely. +1 here.

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @octet-stream on Sat, 30 Jul 2016 18:10:31 GMT

---

I'm not sure, but how about adding these operators as aliases for async and await?
Something like ~> for async and <~ for await
For example, the basic Koa app with this syntax:

  Koa = require 'koa'

  koa = new Koa

  async koa.use (ctx, next) ->
    ctx.body = 'Hello, world!'
    await do next

  koa.listen 2319, -> console.log 'Koa started on http://localhost:2319'

or

  Koa = require 'koa'

  koa = new Koa

  koa.use (ctx, next) ~>
    ctx.body = 'Hello, world!'
    <~ do next

  koa.listen 2319, -> console.log 'Koa started on http://localhost:2319'

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Sat, 30 Jul 2016 02:18:09 GMT

---

To elaborate, the async keyword can be unwieldy, and would be downright confusing on coffeescript:

async -> await bar()

which looks like you're doing this:

async(function(){ await bar(); });

which you're not.

CoffeeScript's two-character function definitions enable more expressive, functional programming styles, and make JavaScript (arguably) more readable and (absolutely) more lightweight. Requiring use of the async keyword would increase the character count by a factor of 4 (2 to 8, including the space).

Most importantly, whether or not a function is asynchronous can be inferred by whether it contains an await. This has strong precedent in CoffeeScript, which infers whether or not a function is a generator based on whether it contains a yield keyword.

The one reason one might want to include async is for explicitness, and I don't think that jibes with coffeescript's general mentality 😉

[coffeescriptbot]

---

Migrated from coffeescript6/discuss#10 (comment)
Originally created by @rattrayalex on Sat, 30 Jul 2016 02:26:41 GMT

---

As for "why introduce new syntax for await?" the primary answer again is brevity and convenience. Once async/await is mainstream, await is likely to be an extremely commonly used keyword, especially in node programs. Basically anytime one would consider calling a promise today, they would probably want to use await in the future.

So code that used to look like this:

foo() ->
  fetch(someUrl)
    .then resp -> 
      resp.json()
    .then json ->
      someTransform(json)

can now look like this:

foo() ->
  resp = await fetch(someUrl)
  json = await resp.json()
  someTransform(json)

or, better yet:

foo() ->
  resp <- fetch(someUrl)
  json <- resp.json()
  someTransform(json)

... which has a substantial keystroke savings, is arguably more clear/readable, and doesn't look like a function call.

In general, CoffeeScript is very light on keywords, which is great because function calls look like keywords.