await on synchronous functions

[Gil Tayar]

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 <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
>
>


-- 
Yours,
Gil Tayar
Software Architect @ Wix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/5e9a5c6d/attachment-0001.html>