One use case is where try-catch statements are required. I've had plenty of
these, and it's either declare the variable ahead of time, or wrap in a
IIFE.
Another use case: early returns and complex logic. This is pretty nice when
you're working with a complex set of conditions for a polyfill. I came
across this conditionally spawning a worker with a static implementation,
which included complex logic, early returns, and try-catch. Only the return
value was needed in the outer scope, so an IIFE simplified it.
```js
;(() => {
if (window.somethingSimple) {
return somethingSimple(foo, bar)
}
let res
// super complex workaround by necessity
return res
})()
```
On Sat, Dec 19, 2015, 17:46 Fabrício Matté <ultco...@gmail.com> wrote:
> On Sat, Dec 19, 2015 at 8:10 PM, <br...@mailed.me.uk> wrote:
>
>> I believe await* has gone from the spec. The correct form would be (at
>> the top-level):
>>
>
> True, I guess `await*` never made it to the proposal's formal text. It
> still worked in Babel the last time I checked, though. FWIW, `await* []`
> would desugar to `await Promise.all([])`.
>
>
>> The mistake in Dimitry's example is that the async body was not resolved,
>> not that anonymous async functions are in some way invalid - they're just
>> fine.
>>
>
> I'm not sure if I understand what you mean. I see that the outer
> synchronous function would not await until the async function finished—i.e.
> the outer function would return before the promise was resolved/settled—,
> but that is still valid syntax—you could be running the async code for
> side-effects that the caller context does not need to be aware of. You
> mentioned this was invalid syntax, and that was the initial point I
> addressed. :)
>
> /fm
> _______________________________________________
> 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
