As I understand it, as currently specified, the first part of an async
function, before the first await statement, is executed synchronously.
This is subject to subtle bugs when used with callbacks, which may be
common with DOM event handlers. Take the following code example:
```js
let
On 05/02/2014 9.43, Brendan Eich wrote:
Can we regain consensus on the September status quo ante, minus any do
both half-hearted compromises that don't work? Mark, what do you think?
For what it's worth, I've been planning to file a bug on GitHub before
I saw the most recent conclusion, that
));
```
Will the state of p3 be more similar to that of p1 or that of p2?
I'll file a bug when I understand the situation better.
Regards,
Paolo
On 28/01/2014 21.07, Paolo Amadini wrote:
I don't have a background on the .flatMap level of abstraction. In the
following scenario, will users of getMyPromise() have
On 29/01/2014 5.12, Kris Kowal wrote:
In this case, a half pursuit of type purity is a side quest at the
expense of users. Having two ways to resolve and two ways to observe a
promise is unnecessarily confusing. In my experience, one method like
then, that unwraps recursively, and one
I have a suggestion about the current draft of the Promises
specification that derives from my experience on the Mozilla code base.
I'm not familiar with how the specification process works, discussion
in this group seemed like a good start.
Those familiar with the subject may find that this
[Replying here since I'm not sure about how to move the discussion to
the issue tracker without losing the context of Mark's observation.]
On 28/01/2014 20.28, Mark S. Miller wrote:
For people concerned only about the .then level of abstraction, I see
little reason to ever use Promise.resolve
6 matches
Mail list logo
