await on synchronous functions

[Ben Newman]

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 <
andrea.giammarchi at gmail.com> 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 <tomvc.be at gmail.com>
> wrote:
>
>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi <andrea.giammarchi at gmail.com
>> >:
>>
>>> 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 <zenparsing at gmail.com>
>>> 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
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/1021fdd2/attachment.html>