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
> 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
On Sat, Oct 12, 2019 at 7:19 AM Andrea Giammarchi
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
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.
The following two examples produce indeed the very same result:
```js
(async
On Fri, Oct 11, 2019 at 1:15 AM Andrea Giammarchi
wrote:
> Again, the `await?` is sugar for the following:
>
> ```js
> const value = await? callback();
>
> // as sugar for
> let value = callback();
> if ('then' in value)
> value = await value;
> ```
Okay, so that has the "you can't predict
Again, the `await?` is sugar for the following:
```js
const value = await? callback();
// as sugar for
let value = callback();
if ('then' in value)
value = await value;
```
but since I've stated already I have no interest anymore in this proposal,
we can also stop explaining to each others
On Wed, Oct 9, 2019 at 11:17 PM Andrea Giammarchi
wrote:
> > What's the order of the logs?
>
> Exactly the same, as the `await?` is inevitably inside an `async` function
> which would grant a single microtask instead of N.
I think you're misreading my example? Check this out:
> What's the order of the logs?
Exactly the same, as the `await?` is inevitably inside an `async` function
which would grant a single microtask instead of N.
Example:
```js
async function tasks() {
await? maybeAsync();
await? maybeAsync();
await? maybeAsync();
}
tasks();
```
If
On Wed, Oct 9, 2019 at 12:08 AM Andrea Giammarchi
wrote:
> I don't know why this went in a completely unrelated direction so ... I'll
> try to explain again what is `await?` about.
Nah, we got it. Our complaint was still about the semantics.
> ```js
> const value = await? callback();
>
> // as
Hi!
First, experiences of this guy
https://medium.com/@bluepnume/intentionally-unleashing-zalgo-with-promises-ab3f63ead2fd
seem to refute the problematicity of zalgo.
Second, I actually have the use case of this pattern (though actually
it's not a use case for a new syntax). In Amber
I had a similar example in real-world code, but it was just to merge
sync and async into the same code path. I handled it by using
generators and basically running them myself:
https://github.com/isiahmeadows/mithril-node-render/blob/v2/index.js#L195-L206
In either case, I'm not sure it's worth
I don't know why this went in a completely unrelated direction so ... I'll
try to explain again what is `await?` about.
My first two examples show a relevant performance difference between the
async code and the sync one.
The async code though, has zero reasons to be async and so much slower.
Have to agree, mixing sync and async code like this looks like a disaster
waiting to happen. Knowing which order your code will be executed in might seem
not so important for controlled environments where micro optimisations are
attractive, but thinking about trying to track down a bug through
I'm not sure I understand the intended use-case here. If the author
knows the function they're calling is async, they can use `await`
normally. If they know it's not async, they can avoid `await`
altogether. If they have no idea whether it's async or not, that means
they just don't understand
> Sure thing, engines might infer returned values in some hot code and skip
the microtask dance once it's sure some callback might return values that
are not promises, but what if developers could give hints about this
possibility?
Engines can't do this, because it would change the observable
15 matches
Mail list logo
