{"action":"opened","issue":{"url":"https://api.github.com/repos/tc39/ecma262/issues/832","repository_url":"https://api.github.com/repos/tc39/ecma262","labels_url":"https://api.github.com/repos/tc39/ecma262/issues/832/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma262/issues/832/comments","events_url":"https://api.github.com/repos/tc39/ecma262/issues/832/events","html_url":"https://github.com/tc39/ecma262/issues/832","id":211517751,"number":832,"title":"ES2017: allowing async method named \"function\" is future hostile","user":{"login":"allenwb","id":505435,"avatar_url":"https://avatars1.githubusercontent.com/u/505435?v=3","gravatar_id":"","url":"https://api.github.com/users/allenwb","html_url":"https://github.com/allenwb","followers_url":"https://api.github.com/users/allenwb/followers","following_url":"https://api.github.com/users/allenwb/following{/other_user}","gists_url":"https://api.github.com/users/allenwb/gists{/gist_id}","starred_url":"https://api.github.com/users/allenwb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/allenwb/subscriptions","organizations_url":"https://api.github.com/users/allenwb/orgs","repos_url":"https://api.github.com/users/allenwb/repos","events_url":"https://api.github.com/users/allenwb/events{/privacy}","received_events_url":"https://api.github.com/users/allenwb/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-03-02T21:06:46Z","updated_at":"2017-03-02T21:06:46Z","closed_at":null,"body":"Summary:\r\n\r\nThe ES2017 draft currently allows this:\r\n```js\r\nclass {\r\n   async function() {}; //this creates an property named \"function\" whose value is an async function object;\r\n}\r\n```\r\n\r\nThis is future hostile because it creates issues if we every want to add lexically scoped declarations to class bodies. It would be more future proof to disallow (via a look-ahead restriction) `function` in the _PropertyName_ position of _AsyncMethod_ . It would still be possible to define an async method named \"function\" by quoting the property name.\r\n\r\nWe should add the look-ahead restriction in the final version of the ES2017 spec.\r\n\r\nTL;DR\r\n\r\nThe possibility of adding lexically scoped declarations to class bodies have long been discussed and is under active discussion, particularly as a complement to private fields. However, consider the following:\r\n\r\n```js\r\nclass {\r\n  async function() {}   //ES2017 draft says this is an async method named \"function\"\r\n  async function helper() {}  //in the future we might want this to be class-scoped async function declaration\r\n}\r\n```\r\nThe problem is that in parsing a _ClassElement_ whose first token is `async` we can't distinguish _AsyncMethod_ and _AsyncFunctionDeclaration_  using single token look-ahead. \r\n\r\nWe should future-proof ES2017 to allow for the future possibility of such declarations.  This can be accomplished by changing the [definition of _AsyncMethod_](https://tc39.github.io/ecma262/#prod-AsyncMethod) to:\r\n\r\n<pre>\r\n<i>AsyncMethod</i><sub>[Yield, Await]</sub> :\r\n&nbsp;&nbsp;&nbsp;<b>async</b> [no <i>LineTerminator</i> here] [lookahead ∉ {<b>function</b>}]&nbsp;<i>PropertyName</i><sub>[?Yield, ?Await]</sub> <b>(</b> <i>UniqueFormalFarameters</i><sub>[~Yield, +Await]</sub> <b>) {</b> <i>AsyncFunctionBody</i> <b>}</b>\r\n</pre>\r\n\r\n**Web compatibility considerations.**\r\n\r\nMost browser are already shipping async methods.  Can we get away with making this change at this late data?  Probably. It's seems likely that very few (if any) websites have yet defined async methods named \"function\".  But we will never know if we don't try to make this change. If we do make this change in the final spec. one or more browser will test it in preview release.  If no compatibility problems are found, we can expect that the change will be widely adopted. If compatibility problems are found the change wouldn't be adopted by browsers and we can remove it in ES2018.  Changing it now in the ES2017 spec. is probably the only opportunity we will have to do this future proofing.\r\n"}}
{"actor":{"display_login":"allenwb"}}