Re: Legitimate uses of IIFEs?

[Dmitry Soshnikov]

But how would you make an async entry point? Say, you have couple of async
functions which you imported, they should be ran sequentily, depending on
each other:

let user = await fetchUser(id);
let scores = user.scores.map(score => score.latest);
let data = await fetchData(scores);

What should be an entry point to this async code, if thete is no top-level
await?

Having an async IIFE for the purpose of an entry point seems fits well
here. How else would you do this, except an async function declaration, and
further its execution?

function asyncEntryPoint() {
  // await here
}

asyncEntryPoint();
  // .then(...); // not needed

Dmitry
On Dec 20, 2015 13:57, "Mat At Bread"  wrote:

> I don't dispute you can do it, I just don't see it as necessary, or at
> least any more necessary than using an IIFE to collect together synchronous
> logic. The creation of the scope is not a factor here.
>
> On 20 December 2015 9:54:59 pm Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>>
>>
>> On Sunday, December 20, 2015,  wrote:
>>
>>> You're quite right, which demonstrates the lack of necessity for a
>>> top-level await (FYI, I find the inconsistency irritating but
>>> understandable), so I still maintain this is not a _required_ use for an
>>> IIAFE - there is no reason to create an async function to invoke another
>>> async function; one can simply invoke it, and if the result/completion is
>>> required, use it's ,then() memberbut there's no need/advantage to
>>> wrapping such an invocation in an IIAFE, right?
>>>
>>>
>> The use case is valid, there was no mistakes. We use async IIFEs as an
>> "entry point" to async code: you can await there, do intermediate
>> calculations with temporary variables, again awai, etc (Promise.all has a
>> different use case).
>>
>> Dmitry
>>
>>
>>
>>>
>>> On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <
>>> for...@lindesay.co.uk> wrote:
>>>
>>> Promises are eager.  That is, they do the work and resolve whether you
>>> await them or not.  If you want to handle exceptions, you need to call
>>> .then and provide an error handler, but other than that it's totally ok to
>>> not bother waiting for a promise.
>>>
>>> On 19 Dec 2015, at 22:02, Mat At Bread  wrote:
>>>
>>> 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 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
>>>   })().then(v => cb(null, v), cb);
>>> }
>>> ```
>>>
>>> /fm
>>>
>>> On Sat, Dec 19, 2015 at 7:11 PM,  wrote:
>>>
>>> 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 <
>>> dmitry.soshni...@gmail.com> wrote:
>>>
>>>
>>>
>>> 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 instances of this pattern:
>>>
>>> var foo = (function () {
>>> var a, b, c; // helper variables
>>> // some computation
>>> return /* final value of foo */;
>>> }());
>>> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
>>> pattern.
>>> Anything else?
>>>
>>>
>>> FWIW, one of the still valid use cases is async IIFE, to spawn an async
>>> code (since there's no yet top-level async/await)
>>>
>>> (async function() {
>>>   // await here
>>> })();
>>>
>>> Dmitry
>>>
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Bergi]

Fabrício Matté schrieb:


Btw, the term "IIAFE" should probably be avoided, as the "A" can
ambiguously mean "Arrow" or "Async".


I've never heard of an "Arrow function expression" - it's just "arrow 
function" :-)

I think it would always be clear from the context anyway.

Regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Andrea Giammarchi]

I'm trying to figure out how worlds based on current modules ecosystem
would work ...

```js
let
  path = require('path'),
  lib = require(path.join(__dirname, 'lib/index.js'))
;
```

How even in an ES2015 world would that look like?

Putting async/await everywhere doesn't seem like a real answer ... or does
it?




On Sun, Dec 20, 2015 at 10:07 PM, Fabrício Matté  wrote:

> On Sun, Dec 20, 2015 at 7:32 PM,  wrote:
>
>> there is no reason to create an async function to invoke another async
>> function; one can simply invoke it, and if the result/completion is
>> required, use it's ,then() memberbut there's no need/advantage to
>> wrapping such an invocation in an IIAFE, right?
>
>
> I believe the advantage is that you can then replace the
> `.then(onFulfilled, onRejected)` constructs with `await/try/catch`, thus
> simplifying the code and improving readability. I recognize this may be an
> uncommon pattern though, as most often the caller of an async function will
> be an async function as well. Note that I say "uncommon" referring to async
> IIFEs inside non-async functions; async IIFEs are still very useful to
> parallelize sequences of async operations as I've mentioned before.
>
> Btw, the term "IIAFE" should probably be avoided, as the "A" can
> ambiguously mean "Arrow" or "Async".
>
> /fm
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Fabrício Matté]

On Sun, Dec 20, 2015 at 8:39 PM, Bergi  wrote:

> I've never heard of an "Arrow function expression" - it's just "arrow
> function" :-)


It is true that the current spec. always refers to the production as
"ArrowFunction". Though, there are threads proposing Arrow Function
Definitions and Arrow Function Method Definitions, so I thought adding
"Expression" would be more future-proof. But indeed, there is currently no
such thing as Arrow Function Expression, so this may be more confusing than
not.

I think it would always be clear from the context anyway.
>

Having to scan through the context to figure out the meaning of a term adds
unnecessary cognitive overhead, and even then it is ambiguous in some
contexts.

/fm
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Bergi]

Andrea Giammarchi schrieb:


Reading this thread felt like one problem is gone and another is coming ...
and to be honest, a `module.exports = new Promise(myModule);` should most
likely become a new standard for asynchronously defined modules in the
node.js world, and I've no idea how that could be represented through the
current ES2015 specs which seem to assume every module loading could be
asynchronous, but the exported behavior would  be definitively sync.


I think a top-level (read: module-level) `await` could solve this quite 
elegantly.



... or maybe I am missing something, like the fact if a module export a
Promise it's automatically usable no matter if the requester was within a
sync execution or async?


That would be up to the loader. But I don't think a module loader should 
mess with these things, for various reasons. Error (=rejection) handling 
would be obscure. Sometimes I *want* to export promises without anyone 
awaiting them. And of course, exports do resolve to variable bindings, 
not to values, so this would be hard to align with the current spec.


Regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Dmitry Soshnikov]

On Sunday, December 20, 2015,  wrote:

> You're quite right, which demonstrates the lack of necessity for a
> top-level await (FYI, I find the inconsistency irritating but
> understandable), so I still maintain this is not a _required_ use for an
> IIAFE - there is no reason to create an async function to invoke another
> async function; one can simply invoke it, and if the result/completion is
> required, use it's ,then() memberbut there's no need/advantage to
> wrapping such an invocation in an IIAFE, right?
>
>
The use case is valid, there was no mistakes. We use async IIFEs as an
"entry point" to async code: you can await there, do intermediate
calculations with temporary variables, again awai, etc (Promise.all has a
different use case).

Dmitry



>
> On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <
> for...@lindesay.co.uk
> > wrote:
>
> Promises are eager.  That is, they do the work and resolve whether you
> await them or not.  If you want to handle exceptions, you need to call
> .then and provide an error handler, but other than that it's totally ok to
> not bother waiting for a promise.
>
> On 19 Dec 2015, at 22:02, Mat At Bread  > wrote:
>
> 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 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
>   })().then(v => cb(null, v), cb);
> }
> ```
>
> /fm
>
> On Sat, Dec 19, 2015 at 7:11 PM,  > wrote:
>
> 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 <
> dmitry.soshni...@gmail.com
> > wrote:
>
>
>
> 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 instances of this pattern:
>
> var foo = (function () {
> var a, b, c; // helper variables
> // some computation
> return /* final value of foo */;
> }());
> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
> pattern.
> Anything else?
>
>
> FWIW, one of the still valid use cases is async IIFE, to spawn an async
> code (since there's no yet top-level async/await)
>
> (async function() {
>   // await here
> })();
>
> Dmitry
>
>
>
> ___
> 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
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Mat At Bread]

I don't dispute you can do it, I just don't see it as necessary, or at 
least any more necessary than using an IIFE to collect together synchronous 
logic. The creation of the scope is not a factor here.



On 20 December 2015 9:54:59 pm Dmitry Soshnikov 
 wrote:



On Sunday, December 20, 2015,  wrote:


You're quite right, which demonstrates the lack of necessity for a
top-level await (FYI, I find the inconsistency irritating but
understandable), so I still maintain this is not a _required_ use for an
IIAFE - there is no reason to create an async function to invoke another
async function; one can simply invoke it, and if the result/completion is
required, use it's ,then() memberbut there's no need/advantage to
wrapping such an invocation in an IIAFE, right?



The use case is valid, there was no mistakes. We use async IIFEs as an
"entry point" to async code: you can await there, do intermediate
calculations with temporary variables, again awai, etc (Promise.all has a
different use case).

Dmitry





On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <
for...@lindesay.co.uk
> wrote:

Promises are eager.  That is, they do the work and resolve whether you
await them or not.  If you want to handle exceptions, you need to call
.then and provide an error handler, but other than that it's totally ok to
not bother waiting for a promise.

On 19 Dec 2015, at 22:02, Mat At Bread > wrote:

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 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
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM, > wrote:

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 <
dmitry.soshni...@gmail.com
> wrote:



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 instances of this pattern:

var foo = (function () {
var a, b, c; // helper variables
// some computation
return /* final value of foo */;
}());
Btw, there is a "do expression" proposal (stage 0) [1] for this type of
pattern.
Anything else?


FWIW, one of the still valid use cases is async IIFE, to spawn an async
code (since there's no yet top-level async/await)

(async function() {
  // await here
})();

Dmitry



___
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



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Fabrício Matté]

On Sun, Dec 20, 2015 at 7:32 PM,  wrote:

> there is no reason to create an async function to invoke another async
> function; one can simply invoke it, and if the result/completion is
> required, use it's ,then() memberbut there's no need/advantage to
> wrapping such an invocation in an IIAFE, right?


I believe the advantage is that you can then replace the
`.then(onFulfilled, onRejected)` constructs with `await/try/catch`, thus
simplifying the code and improving readability. I recognize this may be an
uncommon pattern though, as most often the caller of an async function will
be an async function as well. Note that I say "uncommon" referring to async
IIFEs inside non-async functions; async IIFEs are still very useful to
parallelize sequences of async operations as I've mentioned before.

Btw, the term "IIAFE" should probably be avoided, as the "A" can
ambiguously mean "Arrow" or "Async".

/fm
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Forbes Lindesay]

Promises are eager.  That is, they do the work and resolve whether you await 
them or not.  If you want to handle exceptions, you need to call .then and 
provide an error handler, but other than that it's totally ok to not bother 
waiting for a promise.

On 19 Dec 2015, at 22:02, Mat At Bread 
> wrote:


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 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
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM, 
> wrote:
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 
> wrote:


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 instances of this pattern:

var foo = (function () {
var a, b, c; // helper variables
// some computation
return /* final value of foo */;
}());
Btw, there is a "do expression" proposal (stage 0) [1] for this type of pattern.
Anything else?

FWIW, one of the still valid use cases is async IIFE, to spawn an async code 
(since there's no yet top-level async/await)

(async function() {
  // await here
})();

Dmitry


___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[bread]

You're quite right, which demonstrates the lack of necessity for a top-level 
await (FYI, I find the inconsistency irritating but understandable), so I still 
maintain this is not a _required_ use for an IIAFE - there is no reason to 
create an async function to invoke another async function; one can simply 
invoke it, and if the result/completion is required, use it's ,then() 
memberbut there's no need/advantage to wrapping such an invocation in an 
IIAFE, right?


On 20 December 2015 13:40:30 -00:00, Forbes Lindesay  
wrote:

> Promises are eager. That is, they do the work and resolve whether you await 
> them or not. If you want to handle exceptions, you need to call .then and 
> provide an error handler, but other than that it's totally ok to not bother 
> waiting for a promise.
> 
> 
> On 19 Dec 2015, at 22:02, Mat At Bread <> wrote:
> 
> 
> > 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 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
> > > })().then(v => cb(null, v), cb);
> > > }
> > > ```
> > > 
> > > /fm
> > > 
> > > 
> > > 
> > > On Sat, Dec 19, 2015 at 7:11 PM, <> wrote:
> > > 
> > > 
> > > 
> > > > 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 
> > > > <> wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > 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 instances of this pattern:
> > > > > > 
> > > > > > var foo = (function () {
> > > > > > var a, b, c; // helper variables
> > > > > > // some computation
> > > > > > return /* final value of foo */;
> > > > > > 
> > > > > > }());
> > > > > > 
> > > > > > Btw, there is a "do expression" proposal (stage 0) [1] for this 
> > > > > > type of pattern.
> > > > > > Anything else?
> > > > > > 
> > > > > FWIW, one of the still valid use cases is async IIFE, to spawn an 
> > > > > async code (since there's no yet top-level async/await)
> > > > > 
> > > > > (async function() {
> > > > > // await here
> > > > > })();
> > > > > 
> > > > > Dmitry 
> > > > > 
> > > > 
> > > > ___
> > > > es-discuss mailing list
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > ___
> > es-discuss mailing list
> > 
> > 
> > 
> > 
> >

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Andrea Giammarchi]

Funny I've being advocating IIFE mostly for cross platform modules since I
believe the moment you need an IIFE is because your code is where it
shouldn't, within some other code instead of being in a module a part.

At least that's what JS has been for a while before let and const made it
and before nodejs require or ES2015 import existed.

Reading this thread felt like one problem is gone and another is coming ...
and to be honest, a `module.exports = new Promise(myModule);` should most
likely become a new standard for asynchronously defined modules in the
node.js world, and I've no idea how that could be represented through the
current ES2015 specs which seem to assume every module loading could be
asynchronous, but the exported behavior would  be definitively sync.

... or maybe I am missing something, like the fact if a module export a
Promise it's automatically usable no matter if the requester was within a
sync execution or async?

Thanks whoever for clarification!






On Sun, Dec 20, 2015 at 7:32 PM,  wrote:

> You're quite right, which demonstrates the lack of necessity for a
> top-level await (FYI, I find the inconsistency irritating but
> understandable), so I still maintain this is not a _required_ use for an
> IIAFE - there is no reason to create an async function to invoke another
> async function; one can simply invoke it, and if the result/completion is
> required, use it's ,then() memberbut there's no need/advantage to
> wrapping such an invocation in an IIAFE, right?
>
>
> On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <
> for...@lindesay.co.uk> wrote:
>
> Promises are eager.  That is, they do the work and resolve whether you
> await them or not.  If you want to handle exceptions, you need to call
> .then and provide an error handler, but other than that it's totally ok to
> not bother waiting for a promise.
>
> On 19 Dec 2015, at 22:02, Mat At Bread  wrote:
>
> 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 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
>   })().then(v => cb(null, v), cb);
> }
> ```
>
> /fm
>
> On Sat, Dec 19, 2015 at 7:11 PM,  wrote:
>
> 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 <
> dmitry.soshni...@gmail.com> wrote:
>
>
>
> 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 instances of this pattern:
>
> var foo = (function () {
> var a, b, c; // helper variables
> // some computation
> return /* final value of foo */;
> }());
> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
> pattern.
> Anything else?
>
>
> FWIW, one of the still valid use cases is async IIFE, to spawn an async
> code (since there's no yet top-level async/await)
>
> (async function() {
>   // await here
> })();
>
> Dmitry
>
>
>
> ___
> 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
>
>
>
> ___
> 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