{"action":"created","issue":{"url":"https://api.github.com/repos/zenparsing/js-classes-1.1/issues/39","repository_url":"https://api.github.com/repos/zenparsing/js-classes-1.1","labels_url":"https://api.github.com/repos/zenparsing/js-classes-1.1/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/zenparsing/js-classes-1.1/issues/39/comments","events_url":"https://api.github.com/repos/zenparsing/js-classes-1.1/issues/39/events","html_url":"https://github.com/zenparsing/js-classes-1.1/issues/39","id":305975161,"number":39,"title":"Wrap variables/fields to clarify list and avoid ASI hazards","user":{"login":"leobalter","id":301201,"avatar_url":"https://avatars3.githubusercontent.com/u/301201?v=4","gravatar_id":"","url":"https://api.github.com/users/leobalter","html_url":"https://github.com/leobalter","followers_url":"https://api.github.com/users/leobalter/followers","following_url":"https://api.github.com/users/leobalter/following{/other_user}","gists_url":"https://api.github.com/users/leobalter/gists{/gist_id}","starred_url":"https://api.github.com/users/leobalter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/leobalter/subscriptions","organizations_url":"https://api.github.com/users/leobalter/orgs","repos_url":"https://api.github.com/users/leobalter/repos","events_url":"https://api.github.com/users/leobalter/events{/privacy}","received_events_url":"https://api.github.com/users/leobalter/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2018-03-16T15:36:49Z","updated_at":"2018-03-19T17:28:04Z","closed_at":null,"author_association":"NONE","body":"I like this proposal but I think there is still a gap for ASI hazards here in the var declarations, specially if someone wants to use ASI as a feature (omitting semicolons).\r\n\r\nMy suggestion is to wrap the variable declaration with some characters (here I'm using parentheses).\r\n\r\n```\r\nClassElement [Yield, Await]:\r\n  InstanceFieldsDeclaration [?Yield, ?Await]\r\n  MethodDefinition [?Yield, ?Await]\r\n  HiddenMethod [?Yield, ?Await]\r\n  static MethodDefinition [?Yield, ?Await]\r\n  static HiddenMethod [?Yield, ?Await]\r\n  ClassInitializer\r\n  ;\r\n\r\nInstanceFieldsDeclaration [Yield, Await]:\r\n  fields ( FieldsList ) [?Yield, ?Await]\r\n  \r\nFieldsList\r\n  BindingIdentifier [?Yield, ?Await]\r\n  FieldsList, BindingIdentifier [?Yield, ?Await]\r\n```\r\n\r\nI'm also using fields as the keyword here for the lack of a better idea for now, please replace it with anything else you find better.\r\n\r\n```js\r\nclass C {\r\n  fields ( foo, bar )\r\n}\r\n```\r\n\r\nI also imagine this can be extended with an initializer, but this part might depend on further discussions.\r\n\r\n```\r\nFieldsList\r\n  BindingIdentifier [?Yield, ?Await]\r\n  FieldsList, BindingIdentifier [?Yield, ?Await] Initializer[?Yield, ?Await]_opt\r\n```\r\n\r\nthe current var declaration list avoids ASI hazards only as long it's not extended with initializers, wrapping them would allow it.\r\n\r\n```js\r\nclass A {\r\n  fields (\r\n    foo = 42,\r\n    bar = \"string\"\r\n  ) /* fields end here */\r\n  *gen() {}\r\n}\r\n\r\nclass B {\r\n  fields (\r\n    foo = 42,\r\n    bar = \"string\"\r\n  ) /* same line */ *gen() {}\r\n}\r\n\r\nclass C {\r\n  fields (\r\n    foo = 42,\r\n    bar = \"string\"\r\n  ) [method]() {}\r\n}\r\n```"},"comment":{"url":"https://api.github.com/repos/zenparsing/js-classes-1.1/issues/comments/374297356","html_url":"https://github.com/zenparsing/js-classes-1.1/issues/39#issuecomment-374297356","issue_url":"https://api.github.com/repos/zenparsing/js-classes-1.1/issues/39","id":374297356,"user":{"login":"bakkot","id":1653598,"avatar_url":"https://avatars2.githubusercontent.com/u/1653598?v=4","gravatar_id":"","url":"https://api.github.com/users/bakkot","html_url":"https://github.com/bakkot","followers_url":"https://api.github.com/users/bakkot/followers","following_url":"https://api.github.com/users/bakkot/following{/other_user}","gists_url":"https://api.github.com/users/bakkot/gists{/gist_id}","starred_url":"https://api.github.com/users/bakkot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bakkot/subscriptions","organizations_url":"https://api.github.com/users/bakkot/orgs","repos_url":"https://api.github.com/users/bakkot/repos","events_url":"https://api.github.com/users/bakkot/events{/privacy}","received_events_url":"https://api.github.com/users/bakkot/received_events","type":"User","site_admin":false},"created_at":"2018-03-19T17:28:04Z","updated_at":"2018-03-19T17:28:04Z","author_association":"NONE","body":"@hax,\r\n\r\n> I hope the members of TC39 respect all the efforts devote to simple and viable coding style in last 10 years.\r\n\r\nWe did: that's why class bodies as currently proposed do not require semicolons, leading to those edge cases. From talking to people in the community, I get the impression that those are considered acceptable in exchange for having initialized class fields and not requiring semicolons in bodies in general. I don't think most of those people would be happy with the outcome of simply not having public class fields, as this proposal is advocating, and would instead prefer the existing proposal, including the new edge cases for semi-free style.\r\n\r\nWe're not totally driven by community desires, of course. But if the new edge cases are bad _because_ they would make people unhappy, I think that has to be weighed against how unhappy they would be with not having class fields, which is the main alternative."}}
{"actor":{"display_login":"bakkot"}}