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 adding new syntax for it. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Wed, Oct 9, 2019 at 3:08 AM Andrea Giammarchi <[email protected]> wrote: > > 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 <[email protected]> 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. <[email protected]> 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 >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > 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
