search

tc39 / proposal-function.sent

Generator function.sent Meta Property
MIT License
37 stars 6 forks source link

function.sent as an expression statement. #2

Open nicolo-ribaudo opened 7 years ago

nicolo-ribaudo commented 7 years ago

Hi, while implementing function.sent support in Babel I got a doubt: is this code valid?

function* foo() {
  function.sent;
}

The current specification disallows it (an ExpressionStatement can't start with function): https://tc39.github.io/ecma262/#prod-ExpressionStatement

ExpressionStatement[Yield, Await]:
  [lookahead ∉ { {, function, async [no LineTerminator here] function, class, let [ }] Expression[+In, ?Yield, ?Await] ;

I couldn't find in this proposal a relaxation of that grammar, but I don't see why it should be disallowed.

allenwb commented 7 years ago

Good catch.

Yes, it seems reasonable that an expression statement could start with function . sent. For example, that would be useful for making recursive function calls. So, you should consider that to be part of the proposal.

But, actually specify that via the current ES grammar notation looks like it may be tricky and might even require extending the notation. FunctionDeclaration probably will need a[lookahead ∉ { function . }] guard, but that's not enough. We also need to find a way for ExpressionStatement to express a conditional multi-token lookahead that will allow function .. Maybe something like:

ExpressionStatement[Yield, Await]:
  [lookahead ∉ { {, function [lookahead ∉ { . }], async [no LineTerminator here] function, class, let [ }] Expression[+In, ?Yield, ?Await] ;
nicolo-ribaudo commented 7 years ago

What about using positive lookahead?

ExpressionStatement[Yield, Await]:
  [lookahead ∈ { function . }] Expression[+In, ?Yield, ?Await] ;
  [lookahead ∉ { {, function, async [no LineTerminator here] function, class, let [ }] Expression[+In, ?Yield, ?Await] ;
allenwb commented 7 years ago

yes, adding positive lookahead to the notation is probably the better way to go