| 14:42 | <nicolo-ribaudo> | Does anybody remember why we have a [no LineTerminator here] restriction in arrow functions, before =>? I don't think it's solving any ambiguity |
| 15:31 | <jmdyck> | That restriction was added to the ArrowFunction production in draft 24 of ES6 (roughly April 2014?), if that helps you find notes. |
| 15:42 | <littledan> | I think this was for consistency with async arrow functions |
| 15:47 | <jmdyck> | AsyncArrowFunctions were added in PR #692, a couple years later. |
| 15:47 | <littledan> | yeah but I think this future thing was anticipated |
| 16:10 | <nicolo-ribaudo> | That restriction was added to the ArrowFunction production in draft 24 of ES6 (roughly April 2014?), if that helps you find notes. |
| 16:10 | <nicolo-ribaudo> | async arrow functions also do not need that restriction, I believe it was done just for consistency with the sync version |
| 16:20 | <nicolo-ribaudo> | Looking at https://github.com/tc39/notes/blob/main/meetings/2014-01/jan-30.md#asyncawait it looks indeed like it was added to disambiguate this case: but that's not (and wasn't, at the time) ambiguous 🤔 |
| 16:21 | <nicolo-ribaudo> | The reason I'm asking is because this rule adds some annoying complexity to Babel's code printer (for some reason more than the other no-LineTerminator-here restrictions), and I know that it's also being problematic for tools that do position-preserving type stripping |
| 16:22 | <Andreu Botella> |
async a valid identifier? |
| 16:25 | <nicolo-ribaudo> | isn't |
| 16:26 | <Andreu Botella> | so isn't async (foo) ambiguous with calling an function called async? |
| 16:27 | <nicolo-ribaudo> | The
|
| 16:30 | <nicolo-ribaudo> | Ok, it looks like the reason was for forward compatibility with this proposal: https://bterlson.github.io/headless-arrows/ In the past 10 years nobody pushed for that proposal and even the proposal itself explains why it would be confusing due to async arrow functions, probably we don't need the restriction anymore |
| 16:40 | <littledan> | yeah, that's right, we were discussing headless arrow functions back then. And you don't even need async for that to be ambiguous, e.g., this is ambiguous: |
| 16:40 | <nicolo-ribaudo> | (also, even without the restriction that proposal could still happen, same as we have prefix and infix +) |
| 16:41 | <littledan> | honestly I'd still like some kind of headless arrow functions to happen--they'd make signals more ergonomic! But I'd type them as ^y instead |
| 16:41 | <nicolo-ribaudo> |
|
| 16:42 | <nicolo-ribaudo> | Which I consider perfectly fine -- if somebody likes ASI they just have to learn to prefix lines starting with ^/=> with a semicolon |
| 16:43 | <littledan> | right... it is fine |
| 16:44 | <littledan> | you don't usually want to do an ExpressionStatement with an arrow function anyway! not very useful |
| 17:01 | <bakkot> | oh jeeze I would prefer we not introduce yet another syntax for functions |
| 18:56 | <littledan> | don't worry I'm not actually pushing that (since it seems too unlikely that it'll get consensus) |