I would tend to agree with Tom (i.e. Promisify non-promises), even though we should notice that awaiting a synchronous function adds a non-trivial overhead, because although the promise is immediately resolved, the await will "return" only after being processed in the event loop (if I remember the Promise spec correctly).
So if option #1 has the advantage of "alerting" us to this performance effect, why do I still prefer option #2? Because of consistency - this is similar to the callback the ".then" of a promise accepts: if the callback returns a promise, it is chained, and if it is a regular value, then it is promisified and chained. The same two options exist there, and the spec decided on #2. And rightfully so. I like the fact that the code "just works" and in languages like JS, I would prefer it "just working" than being "statically correct". Dynamic languages lots of time tend to prefer the "just works, albeit slowly" approach to the "theoretically and statically correct" approach. - Gil On Fri, Jul 17, 2015 at 9: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 > > -- Yours, Gil Tayar Software Architect @ Wix
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
