Sorry for making this request now (rather than when async/await was first
being formulated), but real-world use has led me to think some things could
benefit from a slightly different syntax. I also apologise if this has been
raised/discussed before, I wasn't able to find it. The proposal is most
quickly explained with an example.

Current:

class RemoteService {
    async init() { ... }
    async setProp(id, val) { ...; return this }
    async getProp(id) { return ... }
    async runInBackground() { ... }
}

async function remoteExample() {
    let remote = new RemoteService();
    await remote.init();
    await (await remote.setProp('a', 1)).setProp('b', 2);
    remote.runInBackground();
    let val = await remote.getProp('a');
    return val;
}

Proposed:

class RemoteService {
    await init() { ... }
    await setProp(id, val) { ...; return this }
    await getProp(id) { return ... }
    await runInBackground() { ... }
}

await function remoteExample() {
    let remote = new RemoteService();
    remote.init();
    remote.setProp('a', 1).setProp('b', 2);
    async remote.runInBackground();
    let val = remote.getProp('a');
    return val;
}

Why:

Running things in a genuinely asynchronous way is actually *unusual*. The
current async/await syntax (which I think should still stay) is the exact
reverse of what fits the probable use cases. Missing the 'await' keyword
(particularly on functions/methods that don't return a value) causes all
sorts of hard to track down bugs. I myself didn't realise this until I (and
others I work with) started making intense use of async/await.

The new proposed syntax above is obviously much simpler and would be very
hard to get wrong. By contrast, the original syntax has proven surprisingly
difficult to get consistently right. Even now with quite a lot of practice,
I'm occasionally forgetting an await here and there. In addition, patterns
like chaining get ugly *very* quickly. (Although I guess that could also be
fixed with a method-friendly async call syntax.)

If the proposed syntax were available in addition to the current syntax,
you could apply whichever keyword in the function declaration is most
likely applicable at call sites. e.g. runInBackground could be declared
'async' rather than 'await', if you normally expect it to be run in the
background.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171203/8f77dc95/attachment.html>

Sorry for making this request now (rather than when async/await was first
being formulated), but real-world use has led me to think some things could
benefit from a slightly different syntax. I also apologise if this has been
raised/discussed before, I wasn't able to find it. The proposal is most
quickly explained with an example.

Current:

```js
class RemoteService {
    async init() { ... }
    async setProp(id, val) { ...; return this }
    async getProp(id) { return ... }
    async runInBackground() { ... }
}

async function remoteExample() {
    let remote = new RemoteService();
    await remote.init();
    await (await remote.setProp('a', 1)).setProp('b', 2);
    remote.runInBackground();
    let val = await remote.getProp('a');
    return val;
}
```

Proposed:

```js
class RemoteService {
    await init() { ... }
    await setProp(id, val) { ...; return this }
    await getProp(id) { return ... }
    await runInBackground() { ... }
}

await function remoteExample() {
    let remote = new RemoteService();
    remote.init();
    remote.setProp('a', 1).setProp('b', 2);
    async remote.runInBackground();
    let val = remote.getProp('a');
    return val;
}
```

Why:

Running things in a genuinely asynchronous way is actually *unusual*. The
current async/await syntax (which I think should still stay) is the exact
reverse of what fits the probable use cases. Missing the 'await' keyword
(particularly on functions/methods that don't return a value) causes all
sorts of hard to track down bugs. I myself didn't realise this until I (and
others I work with) started making intense use of async/await.

The new proposed syntax above is obviously much simpler and would be very
hard to get wrong. By contrast, the original syntax has proven surprisingly
difficult to get consistently right. Even now with quite a lot of practice,
I'm occasionally forgetting an await here and there. In addition, patterns
like chaining get ugly *very* quickly. (Although I guess that could also be
fixed with a method-friendly async call syntax.)

If the proposed syntax were available in addition to the current syntax,
you could apply whichever keyword in the function declaration is most
likely applicable at call sites. e.g. runInBackground could be declared
'async' rather than 'await', if you normally expect it to be run in the
background.

Sorry for making this request now (rather than when async/await was first
being formulated), but real-world use has led me to think some things could
benefit from a slightly different syntax. I also apologise if this has been
raised/discussed before, I wasn't able to find it. The proposal is most
quickly explained with an example.

Current:

```
class RemoteService {
    async init() { ... }
    async setProp(id, val) { ...; return this }
    async getProp(id) { return ... }
    async runInBackground() { ... }
}

async function remoteExample() {
    let remote = new RemoteService();
    await remote.init();
    await (await remote.setProp('a', 1)).setProp('b', 2);
    remote.runInBackground();
    let val = await remote.getProp('a');
    return val;
}
```

Proposed:

```
class RemoteService {
    await init() { ... }
    await setProp(id, val) { ...; return this }
    await getProp(id) { return ... }
    await runInBackground() { ... }
}

await function remoteExample() {
    let remote = new RemoteService();
    remote.init();
    remote.setProp('a', 1).setProp('b', 2);
    async remote.runInBackground();
    let val = remote.getProp('a');
    return val;
}
```

Why:

Running things in a genuinely asynchronous way is actually *unusual*. The
current async/await syntax (which I think should still stay) is the exact
reverse of what fits the probable use cases. Missing the 'await' keyword
(particularly on functions/methods that don't return a value) causes all
sorts of hard to track down bugs. I myself didn't realise this until I (and
others I work with) started making intense use of async/await.

The new proposed syntax above is obviously much simpler and would be very
hard to get wrong. By contrast, the original syntax has proven surprisingly
difficult to get consistently right. Even now with quite a lot of practice,
I'm occasionally forgetting an await here and there. In addition, patterns
like chaining get ugly *very* quickly. (Although I guess that could also be
fixed with a method-friendly async call syntax.)

If the proposed syntax were available in addition to the current syntax,
you could apply whichever keyword in the function declaration is most
likely applicable at call sites. e.g. runInBackground could be declared
'async' rather than 'await', if you normally expect it to be run in the
background.