I haven't read the whole thread, but I also disliked the ugly
conditional checking I had to do to get faster results.
I agree that this would changed perceived code execution order
(unexpectedly, a breaking change).
I believe that a better solution would be to make it explicit in the
function definition, so that it carries up into caller code:
```js
async? function foo() { ... }
```
Now, the user of the function must be required to use `await?` and
thus has to be forced to think that the `foo` function might possibly
run async, or might not. Using `await` on an `async? function` would
be a runtime error, to further prevent possible confusion and errors.
Only with a construct like `async? function` could I see this becoming
possible, so that there aren't any surprising breaking changes in
downstream projects.
On Tue, Oct 15, 2019 at 12:26 AM Andrea Giammarchi
<[email protected]> wrote:
>
> > You still seem to be misunderstanding what the execution order difference
> > is about.
>
> If to stop this thread you need me to say I am confused about anything then
> fine, "I am confused", but if you keep changing my examples to make your
> point then this conversation goes nowhere, so I am officially out of this
> thread.
>
> Best Regards.
>
> On Mon, Oct 14, 2019 at 10:41 PM Tab Atkins Jr. <[email protected]> wrote:
>>
>> On Sat, Oct 12, 2019 at 7:19 AM Andrea Giammarchi
>> <[email protected]> wrote:
>> > in order to work, `await` must be executed in an async scope/context
>> > (either top level or within a closure).
>> >
>> > In such case, either somebody is awaiting the result of that `async`
>> > execution, or the order doesn't matter.
>>
>> That's definitely not true. I gave you an explicit example where the
>> order differs. That example code is realistic if you're using the
>> async call for side-effects only (and thus don't care about the
>> returned promise), or if you're storing the returned promise in a
>> variable so you can pass it to one of the promise combinators later.
>> In either of these cases the order of execution between the sync and
>> async code can definitely matter.
>>
>> > The following two examples produce indeed the very same result:
>> >
>> > ```js
>> > (async () => { return 1; })().then(console.log);
>> > console.log(2);
>> >
>> > (async () => { return await 1; })().then(console.log);
>> > console.log(2);
>> > ```
>>
>> In both of these cases, you're doing no additional work after the
>> "maybe async" point. That is the exact part that moves in execution
>> order between the two cases, so obviously you won't see any
>> difference. Here's a slightly altered version that shows off the
>> difference:
>>
>> ```js
>> (async () => { 1; console.log("async"); return 3; })().then(console.log);
>> console.log(2);
>>
>> (async () => { await 1; console.log("async"); return 3;
>> })().then(console.log);
>> console.log(2);
>> ```
>>
>> In the first you'll log "async", "2", "3". In the second you'll log
>> "2", "async", "3".
>>
>> > As summary: the proposal was to help engines be faster when it's possible,
>> > but devs are confused by the syntax, and maybeat the end there wouldn't be
>> > as many benefits compared to the apparent confusion this proposal would
>> > add.
>>
>> You still seem to be misunderstanding what the execution order
>> difference is about. Nobody's confused about the syntax; it's clear
>> enough. It just does bad, confusing things as you've presented it.
>>
>> As I said in earlier message, there *is* a way to eliminate the
>> execution-order difference (making it so the only difference would be
>> the number of microtasks when your function awaits *multiple* sync
>> values), which I thought you'd come up with at some point, but I'm
>> pretty sure it was just me misunderstanding what you'd said.
>>
>> ~TJ
>
> _______________________________________________
> 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
