await on synchronous functions

[Dean Landolt]

On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Meaning putting a Promise in a chain of promises is a point of no return
> so I've never seen/heard/imagined a case where you have a promise and
> suddenly you refactor that to be synchronous.
>


This is a great point, and I think makes a good argument against the
refactoring use case. But there are other plenty of other interesting use
cases (e.g. Bergi's IEAFE). Consistent sync/async resolution semantics
would allow you to write generic sync/async handlers, which comes up all
over the place.

This approach neatly cleans up some of the inconsistencies around handling
sync throws vs. rejections vs. *zalgo* throws (usually promise-returning
functions which throw before returning a promise). A try/catch around some
`await` will handle all three cases the same, almost -- there's one small
catch (w/ apologies for the bad pun)...

IIUC the behavior of `Promise.resolve` alone are insufficient to get
identical semantics between sync and async calls -- you'd need to spin the
event loop before rethrowing a sync exception, akin to the behavior of
bluebird's `Promise.try`. A minor detail, but punting on this would force
users into wrapping every call with something like `Promise.try`, which
seems like a shame. ISTM these `try` semantics, rather than
`Promise.resolve`, are more natural as the foundation for `await`.


The specific "Promise gonna  Promise" was actually mentioning another
> thread about cancelability and the fact "Promises are Promises and  should
> just Promise" :-)
>
> Sorry for the confusion
>
> On Fri, Jul 17, 2015 at 10:41 PM, Mark S. Miller <erights at google.com>
> wrote:
>
>> Hi Andrea, what do you mean by "Promise must Promise"? I've never seen
>> this phrase before.
>>
>>
>> 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
>>>
>>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>
> _______________________________________________
> 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/20150720/a771c3e1/attachment.html>