| 04:38 | <jschoi> | I'm abso going to block any attempt to make the topic sigil # was even on the table again for a while is because it had looked like that @[] might be viable for tuple literals. But the reception I got from some TC39 representatives was cool, so out it went again… |
| 15:47 | <TabAtkins> | Right |
| 19:00 | <rkirsling> | I do still feel #_ to be an option worth remembering 😅 |
| 19:20 | <jschoi> | I’d be happy to add #_ to the slides. We need to properly consider every still-viable possibility at the next plenary meeting. It was my mistake that ^^ was not properly discussed in the 2021-11-15 incubator meeting. |
| 19:26 | <jschoi> | I’ve added #_ to the slides. For what it’s worth, I feel (moderately) that #_ is less ASCII soupy / visually noisy than ## when mixed with tuple/record literals. |
| 22:21 | <jschoi> | …Should we consider bare @ again? x |> @(0); technically would not be ambiguous, because there is no following class expression. It just requires lookahead to the end of the parentheses… |
| 22:22 | <jschoi> | I want to make sure we aren’t excluding anything that might be viable from the plenary discussion next week, and we’ve always dismissed single @ because of @(expr) class {} decorator syntax, but it isn’t actually ambiguous. |
| 22:23 | <jschoi> | …I suppose ASI would be the problem. |
| 22:24 | <jschoi> | But the ASI problem may not be insurmountable, and either way probably would be at least worth talking about at plenary. |
| 22:51 | <jschoi> | Come to think of it, even if @ is the topic token, x |> @(blah) class C {} would be a SyntaxError because the @ indicates a decorator, and therefore the pipe body has no topic reference……so arguably this isn’t even an ASI hazard. And this scenario (a decorator expression in a pipe body) will hopefully be quite uncommon anyway… |
| 23:12 | <jschoi> | Also rkirsling: I had forgotten that #_ in this is already valid syntax, and therefore x |> #_ in this would be ambiguous between #_ as topic and #_ as private field (since the LHS of in can be an arbitrary expression). So #_ as topic is probably not viable, sorry. |
| 23:15 | <jschoi> | …I suppose we could make a special case with a cover grammar such that #_ in this always means #_ as private field and not as topic, but that seems bad. |
| 23:19 | <rkirsling> | hm I was aware of that case when I suggested it, but I'm not sure why I felt that it didn't affect viability |
| 23:20 | <rkirsling> | becoming unable to do something is certainly not good |
| 23:21 | <rkirsling> | @ would be amazing if it were viable. |
| 23:22 | <jschoi> | Yeah, it would be such a huge boon if the topic could be one character long. |
| 23:23 | <jschoi> | And developers should be encouraged to keep their pipe bodies short and simple…and decorated expressions are almost never short or simple, so they almost never should be in pipe bodies anyway. So I don’t think this ASI hazard is much of a hazard. |