it would be nice to have async-blocks like ``async {some_statements}`` and ``async (some_expression)``

Jordan Harband ljharb at gmail.com
Tue Jan 3 15:16:29 UTC 2017


That would create a refactoring hazard if i had the block: `{ a(); b();
return c(); }` and stuck the `async` keyword in front of it - suddenly the
function wouldn't have an early completion in the block, it'd create and
throw away a Promise.

On Tue, Jan 3, 2017 at 12:52 AM, Igor Baklan <io.baklan at gmail.com> wrote:

> I looks like it would be nice to have ``async``-block which might be alias
> to ``async``-lambda immediate invocation, so that:
>
> ```js
> var promise = async { /*some statements with await*/ };
> ```
> <==>
>
> ```js
> var promise = (async () => { /*some statements with await*/ }) ();
> ```
>
> and
>
> ```js
> var promise = async ( /*some statements with await*/ );
> ```
> <==>
>
> ```js
> var promise = (async () => ( /*some expression with await*/ )) ();
> ```
>
> Then it can gave some convenience in writing some semi-async function,
> like for example parallel async batch processing, which might look like:
>
> ```js
> const backupBatch = (batch) => {
>   var tasks = [];
>   for (let item of batch) {
>     tasks.push(
>       async {
>         const content = await readContent(item);
>         await writeContent(item + ".bak", content);
>       }
>     )
>   }
>   return Promise.all(tasks)
> }
> ```
>
> or like
>
> ```js
> const backupBatch = (batch) => {
>   var tasks = [];
>   for (let item of batch) {
>     tasks.push(
>       async (
>         await writeContent(item + ".bak", await readContent(item));
>       )
>     )
>   }
>   return Promise.all(tasks)
> }
> ```
>
> of course this simplistic case can be rewritten without ``async``-block
> like:
>
> ```js
> const backupBatch = (batch) => {
>   return Promise.all(
>     batch.map(
>       async (item) => (
>         await writeContent(item + ".bak", await readContent(item));
>       )
>     )
>   );
> }
> ```
> However I believe this not reduce usefulness of initial ``async``-block
> construction.
>
> Also it should be mentioned that this idea "is't new", something very
> similar I saw in [[async-do]](/topic/support-syntax#content-5) comment.
>
> And finally, if this construct will  be introduced, it will provide some
> nice symmetry - of whether you put async keyword in function header
> definition, or at the very beginning of its body, like:
>
> ```js
> const asyncFunc = async (/*args*/) => {/*function body with await-s*/};
> ```
> <==>
> ```js
> const asyncFunc = (/*args*/) => { return async {/*function body with
> await-s*/} };
> ```
> <==>
> ```js
> const asyncFunc = (/*args*/) => ( async {/*function body with await-s*/} );
> ```
>
> And
> ```js
> const asyncFunc = async (args) => (some_async_expression);
> ```
> <==>
> ```js
> const asyncFunc = (args) => async (some_async_expression);
> ```
>
> By the way parentheses here is essential, since ``async x => x`` !=
> ``async (x => x)``, cause first evaluates into async-function, while the
> second should be evaluated into completed promise which value is ``sync``
> function ``(x => x)``.
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170103/66d7c366/attachment.html>


More information about the es-discuss mailing list