Ok, I'm convinced :)
Whether the solution is to invent new syntax or not is moot. It occurred to me
that 'async' could be used as a modifier preceding a block, e.g.
async {
let user = await fetchUser(id);
let scores = user.scores.map(score => score.latest);
let data = await fetchData(scores);
}
...with the caveat (of course) that the body will execute out of order. Or
possibly modify the 'do' specification to stipulate that the body of the do {}
has the semantics of an async function body, allowing 'await' to be implemented
as a keyword. This would seem to fit in better with the OPs observation that
do, amongst other constructs, renders IIFEs less necessary than before.
On 20 December 2015 23:48:42 -00:00, Dmitry Soshnikov
<[email protected]> wrote:
> 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" <<[email protected]>> 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
> > <<[email protected]>> wrote:
> >
> > >
> > >
> > > On Sunday, December 20, 2015, <<[email protected]>> 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() member....but 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 <> 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
> > > > > > > >
> > > > > > > > <https://mail.mozilla.org/listinfo/es-discuss>
> > > > > > > >
> > > > > > > >
> > > > > > _______________________________________________
> > > > > > es-discuss mailing list
> > > > > >
> > > > > > <https://mail.mozilla.org/listinfo/es-discuss>
> > > > > >
> > > >
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
