Yes, I am asking about case #2. Thanks for clarifying Chris. For what it's worth, Traceur allows this now.
On Fri, Jul 17, 2015 at 2:36 PM, Chris Toshok <[email protected]> wrote: > I think we're confusing two different cases here: > > 1) usage of `await` in the body of a function that is not itself marked as > `async` > 2) usage of `await f()` where `f` is not marked as `async`. > > 1 is easy to mark as an early error (and should be imo). 2, not so much > (and is what Mark was asking?) > > -c > > > On Fri, Jul 17, 2015 at 12:30 PM, Ben Newman <[email protected]> > wrote: > >> If we stick with the rule that await is only regarded as a keyword if it >> appears in the body of an async function, then await x without async is >> simply a syntax error, and we can avoid having to answer this question! >> >> That said, perhaps a more natural way of handling wayward await >> expressions is to treat them as referring to the closest enclosing async >> function on the call stack (not necessarily the immediate enclosing >> function), throwing an exception if there is no async function on the >> stack. Then any await expression would delay the resolution of the Promise >> returned by whatever async function is currently executing. The >> same-function-body syntax restriction is a special case of that more >> general model (and notably easier to implement by transpiling to >> generators!). >> >> Generalizing async/await in this way turns out to be equivalent to >> introducing coroutines into the language, and while I would love to see >> that happen one day (it would greatly simplify writing parallel forEach >> loops, for example), it would require substantial changes to the execution >> model of the language. >> >> Here are some slides from a talk I gave earlier this year about the >> benefits and pitfalls of coroutines, in case you're interested: >> http://benjamn.github.io/goto2015-talk >> 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 >>> >> >> _______________________________________________ >> 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 > > -- R. Mark Volkmann Object Computing, Inc.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
