Just a few points to be careful about: Several people have been trying to assert in threads that await can be used to solve synchronous problems; but just like Dean stated, you need to turn the event loop which makes it problematic for things like https://github.com/whatwg/loader/issues/54 need to be sure we do not get confused.
I want to make sure that any proposal does not squash the idea of Compositional Functions ( https://github.com/jhusain/compositional-functions/ ). For various reasons we do not use async/await with promises currently and use the same semantics as compositional promises due to resource management. On Mon, Jul 20, 2015 at 10:57 AM, Dean Landolt <[email protected]> wrote: > > > On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi < > [email protected]> wrote: > >> Meaning putting a Promise in a chain of promises is a point of no return >> so I've never seen/heard/imagined a case where you have a promise and >> suddenly you refactor that to be synchronous. >> > > > This is a great point, and I think makes a good argument against the > refactoring use case. But there are other plenty of other interesting use > cases (e.g. Bergi's IEAFE). Consistent sync/async resolution semantics > would allow you to write generic sync/async handlers, which comes up all > over the place. > > This approach neatly cleans up some of the inconsistencies around handling > sync throws vs. rejections vs. *zalgo* throws (usually promise-returning > functions which throw before returning a promise). A try/catch around some > `await` will handle all three cases the same, almost -- there's one small > catch (w/ apologies for the bad pun)... > > IIUC the behavior of `Promise.resolve` alone are insufficient to get > identical semantics between sync and async calls -- you'd need to spin the > event loop before rethrowing a sync exception, akin to the behavior of > bluebird's `Promise.try`. A minor detail, but punting on this would force > users into wrapping every call with something like `Promise.try`, which > seems like a shame. ISTM these `try` semantics, rather than > `Promise.resolve`, are more natural as the foundation for `await`. > > > The specific "Promise gonna Promise" was actually mentioning another >> thread about cancelability and the fact "Promises are Promises and should >> just Promise" :-) >> >> Sorry for the confusion >> >> On Fri, Jul 17, 2015 at 10:41 PM, Mark S. Miller <[email protected]> >> wrote: >> >>> Hi Andrea, what do you mean by "Promise must Promise"? I've never seen >>> this phrase before. >>> >>> >>> On Fri, Jul 17, 2015 at 11:35 AM, Andrea Giammarchi < >>> [email protected]> wrote: >>> >>>> > Think about a large program where you refactor a single async >>>> function to no longer be async >>>> >>>> did that ever happened in the history of logic? I am actually curious >>>> to understand a single valid case where that would be a solution to any >>>> problem. >>>> >>>> Apologies if I can't see your point but we've been talking about >>>> "Promise must Promise" so much this answer was absolutely unexpected. >>>> >>>> Thanks for any sort of clarification >>>> >>>> On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem <[email protected]> >>>> wrote: >>>> >>>>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi < >>>>> [email protected]>: >>>>> >>>>>> If I might, if there's one thing that has never particularly shone in >>>>>> JS, that is consistency. >>>>>> >>>>>> I see only two possibilities here: 1) it throws with non Promises 2) >>>>>> it "Promisify" anything that's not a Promise as if it was a >>>>>> `Promise.resolve(1)` ... but since there's too much magic in the second >>>>>> point, I'd rather stick with the first one. >>>>>> >>>>> >>>>> I would be highly in favor of (2). Think about a large program where >>>>> you refactor a single async function to no longer be async. Then I see no >>>>> reason why I should be forced to refactor all of its callers to remove the >>>>> await keyword. Going from sync to async requires refactoring because >>>>> you're >>>>> introducing new potential interleaving hazards, but any code that is >>>>> already prepared to work with async functions (or promises in general) >>>>> should work equally fine on immediately resolved promises. >>>>> >>>>> regards, >>>>> Tom >>>>> >>>>> >>>>> >>>>>> >>>>>> Just my quick thoughts >>>>>> >>>>>> Best Regards >>>>>> >>>>>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I know the spec for this isn't finalized, but what is the current >>>>>>>> direction for the behaviour when await is used on a function that is >>>>>>>> not >>>>>>>> marked async and doesn't return a Promise? Should it run immediately or >>>>>>>> wait for the next turn of the event loop? >>>>>>>> >>>>>>> >>>>>>> More generally, the question is: what should await do for >>>>>>> non-promises? >>>>>>> >>>>>>> await 1; >>>>>>> >>>>>>> Should it force a job to be queued? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> es-discuss mailing list >>>>>>> [email protected] >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
