`new Promise(` should be seen as a bridge, used only for interfacing with asynchronicity that does not use promises. (Such as Nodebacks, setTimeout, or older DOM interfaces.) Otherwise you can just return the promise and chain off of it, or await it. (There are some other use cases, such as writing promise combinators, but they are fairly advanced; "library code" and not "application code.")

As such I don't think it's fruitful to introduce new syntax to help these cases. It's fine for them to have the extra few characters and indentation level. The focus should instead be on replacing such older interfaces with promise-returning ones.

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark Volkmann
Sent: Sunday, March 30, 2014 09:06
To: es-discuss at mozilla.org
Subject: await and promise

I looked at the "async" keyword examples in Traceur for the first time today. Cool stuff!

IIUC, when a function is annotated with the async keyword, it can use "await" and the "done" function is magically defined.

An interesting corollary to that idea would be to introduce a "promise" keyword that can be used to annotate a function. It would magically define the functions "resolve" and "reject". It would allow a function like this:

function foo() {
  return new Promise((resolve, reject) => {
    // some code that eventually calls resolve or reject
  });
}

to be written like this:

promise function foo() {
  // some code that eventually calls resolve or reject
}

Is this a crazy idea? Perhaps if this was available, it would be very rare to actually write "new Promise(" in code.

--
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140330/f1f60322/attachment-0001.html>

`new Promise(` should be seen as a bridge, used only for interfacing with asynchronicity that does not use promises. (Such as Nodebacks, setTimeout, or older DOM interfaces.) Otherwise you can just return the promise and chain off of it, or await it. (There are some other use cases, such as writing promise combinators, but they are fairly advanced; "library code" and not "application code.")

As such I don't think it's fruitful to introduce new syntax to help these cases. It's fine for them to have the extra few characters and indentation level. The focus should instead be on replacing such older interfaces with promise-returning ones.