Re: Legitimate uses of IIFEs?

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

Re: Legitimate uses of IIFEs?

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

Legitimate uses of IIFEs?

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

Re: Legitimate uses of IIFEs?

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

Re: Legitimate uses of IIFEs?

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

Re: Legitimate uses of IIFEs?

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

Re: Legitimate uses of IIFEs?

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

Re: Legitimate uses of IIFEs?

@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

Re: Legitimate uses of IIFEs?

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 -

Re: Legitimate uses of IIFEs?

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*

Re: Legitimate uses of IIFEs?

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

Re: Propose simpler string constant

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