I would expect any implementation to do #2 since that's what the draft spec says.
On Fri, Jul 17, 2015 at 12:40 PM, Mark Volkmann <[email protected]> wrote: > 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 > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
