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
