await on synchronous functions

[Mark Volkmann]

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 <toshok at gmail.com> 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 <benjamin at cs.stanford.edu>
> 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 <
>> 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
>>>
>>
>> _______________________________________________
>> 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
>
>


-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/a712b245/attachment.html>