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.
```js
(async () => {
console.time('await');
const result = await (async () => [await 1, await 2, await 3])();
console.timeEnd('await');
return result;
})();
```
Why would `await 1` ever need to create a micro task, if already executed
into a scheduled one via async?
Or in general, why any callback that would early return a value that is not
a promise should create a micro task?
So the proposal was implemented in an attempt to de-sugar `await?` into the
steps proposed by the dev I've interacted with:
```js
const value = await? callback();
// as sugar for
let value = callback();
if ('then' in value)
value = await value;
```
The order is guaranteed and linear in every case, so that nothing actually
change logically speaking, and the hint would be about performance, 'cause
engines don't apparently optimize non-promise based cases.
However, since the initial intent/proposal about performance got translated
into everything else, I've instantly lost interest myself as it's evident
an `await?` would causes more confusion than it solves.
I am also not answering other points as not relevant for this idea/proposal.
Thanks regardless for sharing your thoughts, it helped me see it would
confuse developers.
Best Regards
On Tue, Oct 8, 2019 at 11:58 PM Dan Peddle <d...@flarework.com> wrote:
> 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 this
> would drive me nuts.
>
> Imagine you have a cached value which can be retrieved synchronously -
> other code which runs in order, and perhaps not directly part of this
> chain, would be fine. When it’s not there, zalgo would indeed be released.
> The solution to this is to use promises (as I’m sure you know) so you have
> a consistent way of saying when something is ready... otherwise it’s
> thenable sniffing all the way through the codebase.
>
> Async infers some kind of IO or deferred process, scheduling. If there’s a
> dependency, then we need to express that. That it may be in some cases
> available synchronously seems like something to be extremely wary of.
>
> > On 8. Oct 2019, at 22:25, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
> >
> > 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 what the function is returning, which
> > sounds like a really bad thing that they should fix? And in that
> > case, as Gus says, `await?`'s semantics would do some confusing things
> > to execution order, making the line after the `await?` either run
> > *before* or *after* the calling code, depending on whether the await'd
> > value was a promise or not.
> >
> > ~TJ
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
