Which is what I said, I hope. Use the .then for top-level invitation.
Dimitry's example wouldn't resolve the Promise
On 19 December 2015 9:24:04 pm Fabrício Matté wrote:
@bread I see you are referencing Dmitry's sample, but why do you say it
won't work? AFAIK async
That’s not going to work. The correct form still requires an (illegal)
top-level await:
await (async function() {
// await here
})();
The easiest way to spawn a top-level async function is:
here.then(function(result){},function(error){}) ;
On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov
With block statements + let/const, IIFEs are no longer needed to emulate
block-scoped variables. That got me thinking, are there other uses of
IIFEs, or are they no longer needed?
I’ve checked my code and found instances of this pattern:
var foo = (function () {
var a, b, c; // helper
You can use II(A)FE to summon strict mode in sloppy contexts (such as
Chrome's DevTools console):
```js
(() => {
'use strict';
// ...
})();
```
This is useful as Chrome either does not implement or uses legacy semantics
for quite a few ES2015 features in sloppy mode (e.g. let, const).
As
Good call, Dmitry. Async IIFEs are also useful to parallelize different
sequences of async operations. E.g.:
```js
async function main() {
await* [
(async () => await seq1op2(await seq1op1()))(),
(async () => {
await seq2op1();
await seq2op2();
})(),
];
}
```
Here is
Note that currently, you can't set the language mode in a do-expression. Of
course that could change, i think they're wanting to change a bunch of other
things already.
> On Dec 19, 2015, at 2:54 PM, Fabrício Matté wrote:
>
> You can use II(A)FE to summon strict mode in
On Saturday, December 19, 2015, Šime Vidas wrote:
> With block statements + let/const, IIFEs are no longer needed to emulate
> block-scoped variables. That got me thinking, are there other uses of
> IIFEs, or are they no longer needed?
>
> I’ve checked my code and found
@bread I see you are referencing Dmitry's sample, but why do you say it
won't work? AFAIK async functions return promises, so you don't necessarily
need a top-level `await`. I believe this (extremely ugly) sample should
work:
```js
function f(cb) {
(async function() {
// await here
I believe await* has gone from the spec. The correct form would be (at the
top-level):
```js
Promise.all(asyncFn1(...), asyncFn2(...),...).then(...)
```
The mistake in Dimitry's example is that the async body was not resolved, not
that anonymous async functions are in some way invalid -
On Sat, Dec 19, 2015 at 8:10 PM, 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*
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
Hi Rick, thanks to you and Mike for drafting. I will read and comment more
when I have time, but I wanted to channel the Twitter-ghost of Dave Herman:
"we should start from pattern matching and work our way from there into the
kinds of datatypes we want to match on"
I hear wycats and bterlson
12 matches
Mail list logo