CS2 Discussion: Features: async/await

[rattrayalex]

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.

[DomVinyard]

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

[carlmathisen]

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

[rattrayalex]

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.

[rattrayalex]

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

[rattrayalex]

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?

[rattrayalex]

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

[DomVinyard]

@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.

[rattrayalex]

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

[DomVinyard]

@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.

[octet-stream]

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

[rattrayalex]

@octet-stream verbosity.

😉

[rattrayalex]

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 😉