>
>
> To say a bit more, if we don't want 'yield' in the body of an arrow to
> imply that that arrow function is a generator function, then the same
> argument seems to apply to 'await'. So we need a sigil or equivalent. But
> =>! is at least as infeasible as =>*. So perhaps we cannot reserve 'await'
> in ES6 arrows.
>
>
I think there is reason to think of "arrows generators" and async arrows as
sufficiently different cases to warrant different choices.

The design niche of arrows is "lightweight functional mappings".
 Generators don't define mappings, they define sequences.  Hence arrow
generators don't make a whole lot of sense.

On the other hand, async arrows make perfect sense as "lightweight
functional mappings to Promise<T>".

To my mind, we will almost certainly want async arrows as soon as we have
async functions.  Sure, we can always introduce ever-more grawlixy
notation.  But why commit ourselves to that?  It costs almost nothing to
reserve "await" now.

Let me present a possible future syntax choice:

    AsyncFunctionDeclaration:
        "async" "function" BindingIdentifier ...
        "async" [NoNewLine] BindingIdentifier ...

        async function F() {}
        async F() {}

    AsyncFunctionExpression:
        "async" "function" BindingIdentifier [opt] ...
        "async" [NoNewLine] BindingIdentifier ...

        let F = async function() {});
        let F = async ƒ() {};

    AsyncMethodDefinition:
        "async" PropertyName ...

        ({ async F() {} });

    And any arrow function with an await expression is an async arrow
function.

The non-arrow productions allow the user to define the base case of an
async function without an await expression.  For arrow functions, It will
be obvious to the user that an arrow containing an await expression is
indeed an async function.  In fact, that "inference" fits perfectly well
with the syntax-light nature of arrow functions.

And the fact that we don't have to introduce unnecessary grawlix makes life
easier for those learning the language.

That's one possible future, anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131211/50b3562c/attachment.html>

> To say a bit more, if we don't want 'yield' in the body of an arrow to
> imply that that arrow function is a generator function, then the same
> argument seems to apply to 'await'. So we need a sigil or equivalent. But
> =>! is at least as infeasible as =>*. So perhaps we cannot reserve 'await'
> in ES6 arrows.
>
>

I think there is reason to think of "arrows generators" and async arrows as
sufficiently different cases to warrant different choices.

The design niche of arrows is "lightweight functional mappings".
 Generators don't define mappings, they define sequences.  Hence arrow
generators don't make a whole lot of sense.

On the other hand, async arrows make perfect sense as "lightweight
functional mappings to Promise<T>".

To my mind, we will almost certainly want async arrows as soon as we have
async functions.  Sure, we can always introduce ever-more grawlixy
notation.  But why commit ourselves to that?  It costs almost nothing to
reserve "await" now.

Let me present a possible future syntax choice:

    AsyncFunctionDeclaration:
        "async" "function" BindingIdentifier ...
        "async" [NoNewLine] BindingIdentifier ...

        async function F() {}
        async F() {}

    AsyncFunctionExpression:
        "async" "function" BindingIdentifier [opt] ...
        "async" [NoNewLine] BindingIdentifier ...

        let F = async function() {});
        let F = async ƒ() {};

    AsyncMethodDefinition:
        "async" PropertyName ...

        ({ async F() {} });

And any arrow function with an await expression is an async arrow
function.

The non-arrow productions allow the user to define the base case of an
async function without an await expression.  For arrow functions, It will
be obvious to the user that an arrow containing an await expression is
indeed an async function.  In fact, that "inference" fits perfectly well
with the syntax-light nature of arrow functions.

And the fact that we don't have to introduce unnecessary grawlix makes life
easier for those learning the language.

That's one possible future, anyway.