| 00:32 | <Justin Ridgewell> | You have a few “bind-this” in the ECOSYSTEM SCHISM—FUTURE RISK section |
| 00:32 | <Justin Ridgewell> | Also a “migration to the latter from the latter” |
| 02:45 | <jschoi> | Justin Ridgewell: Thank you; fixed. : ) |
| 15:45 | <jschoi> | FYI: I’m presenting about pipe now. |
| 16:05 | <jschoi> | We agreed generally on single @ for the topic reference. |
| 16:06 | <sarahghp> | 😭 |
| 17:23 | <pokute> | I'm actually quite positively surprised. |
| 17:24 | <rkirsling> | I'm surprised by the decorator advancement so I'm also surprised by this in that context |
| 17:24 | <rkirsling> | but hey, that means that no one should be overlooking anything :) |
| 17:40 | <pokute> | Is class C { @(decFun) m() {} } allowed in decorators? It seems to be, based on Decorators Playground. |
| 17:41 | <ljharb> | i'd expect it to be; @(<expr>) should work for any expression |
| 17:44 | <pokute> | const decoratedLogger = console.log |> @(decFun) function f(param) { @(param) } will be pretty difficult to parse, both for mind and matter. Fortunately it will probably be rare. |
| 17:47 | <pokute> | Well, we don't have to wait for free function decorators either. I think the same might happen with class decorators too. |
| 17:57 | <jschoi> | |
| 17:58 | <jschoi> | We also should encourage developers to keep pipe bodies simple. Linters should probably ban class expressions and decorated functions in pipe bodies. |
| 18:01 | <ljharb> | i think most of that would be overstepping |
| 18:01 | <ljharb> | in general, anything that works outside a pipe body should work inside it, modulo a very few things that would otherwise be serious footguns |
| 18:02 | <jschoi> | Yeah, I’m talking about linting, which can afford to be more opinionated. Maybe that’s too restrictive though, yeah. |
| 18:02 | <ljharb> | in linting it's fine |
| 18:02 | <ljharb> | but we don't specify linters |
| 18:03 | <jschoi> | Yeah, sorry, here I’m also talking about developer education on how to use the operator, which isn’t part of the specification but is still important. |
| 18:11 | <ljharb> | right, i think i misread your earlier comments |
| 18:11 | <ljharb> | we're on the same page |
| 18:32 | <pokute> | Yeah, from fleshy reader perspective, that situation should be very rare / witnessing a "crime" against sensibility in code. From a machine parser perspective, I believe it does require lookahead for class / parameter / function / codeblock / do {} when encountering an @(expr). All except the first are still only possible extensions to decorators. |
| 18:36 | <pokute> | Which is still a ton better situation than # has. Most other token candidates have some kind of readability problems when thought about enough. |
| 18:56 | <pokute> | Ah, I noticed the point in the slide about |> @(@). So basically encountering a |> (@(expr)) would require different parser behaviour. |
| 18:59 | <jschoi> | Ah, I noticed the point in the slide about |> @(@), |> (@(@)), |> @(expr), and |> (@(expr)) will be all valid. However, |> @(@) class {} and |> @(expr) class {} will be early errors. |
| 18:59 | <jschoi> | |> (@(@) class {}) is valid. |
| 18:59 | <jschoi> | |> (@(expr) class {}) is an error (because no topic in the pipe body). |
| 19:00 | <pokute> | I meant requiring parser lookahead in the valid cases. |
| 19:01 | <jschoi> | Ah, yes, @ ( will require lookahead until just after ). |
| 19:02 | <jschoi> | (There is an open question on whether spaces after @ will be allowed in decorators: https://github.com/tc39/proposal-decorators/issues/430 …I am not sure on what its status is because decorators are Stage 3 now.) |
| 19:04 | <ljharb> | wouldn't that just be unbounded lookahead then? |
| 19:04 | <ljharb> | because inside the parens could be an IIFE with a default argument that is itself an IIFE, etc |
| 19:05 | <nicolo-ribaudo> | It's unbounded lookahead but I don't think you need to re-parse the parentheses contents, so it's not much expensive |
| 19:05 | <jschoi> | Yeah, it’s just switching between what to do with the expression that got already parsed inside @( ). |
| 19:06 | <TabAtkins> | It just changes from "treat it like a decorator" vs "call the topic as a function and pass it as the argument", right? |
| 19:06 | <jschoi> | Yes. |
| 19:07 | <jschoi> | No cover grammar needed either. It’s an ordinary expression inside the @( ) either way. |
| 19:07 | <TabAtkins> | yup |
| 19:07 | <pokute> | I didn't notice in the slides, but I guess the mentions of @(@) mean that decFun |> @@ class () {} is illegal? |
| 19:08 | <jschoi> | Yes; @@ is not a valid decorator. |
| 19:08 | <TabAtkins> | did you mean to put some parens in there? |
| 19:08 | <jschoi> | decFun |> @(@) class {} is also illegal; decFun |> (@(@) class {}) is legal. |
| 19:08 | <TabAtkins> | ah yeah, @ isn't an ident so it's not valid after an @ to name a decorator, same as {@: 1} is invalid even if the topic is a string |
| 19:10 | <TabAtkins> | jschoi: is that first code sample illegal by fiat, or is it falling out of some rule in a way i'm not seeing? |
| 19:10 | <jschoi> | jschoi: is that first code sample illegal by fiat, or is it falling out of some rule in a way i'm not seeing? |
| 19:10 | <jschoi> | Otherwise this confusing no-semicolon code would be valid: |
| 19:10 | <TabAtkins> | okay, so fiat. kk |
| 19:18 | <jschoi> | If the other co-champions are fine with it, I plan to update the explainer and specification to use @ sometime in the next month. |
| 19:19 | <pokute> | Well, I like this token. It's single character and it seems like the only apparent complicated case has both well defined rules for how to avoid ambiguousness and apparent ability to give good error messages on rule breaking that help comply with the rules. |
| 19:20 | <TabAtkins> | yeah, @ is a nice chunky token that has similar aesthetics to # for me personally, so I'm satisfied with the resolution. |
| 19:20 | <TabAtkins> | (Sorry, btw, that I couldn't attend this morning, but I've been editting notes from your topics as penance.) |
| 20:39 | <shu> | i have a topic token suggestion, can i shitpost more or have you had enough of me for today TabAtkins |
| 20:39 | <TabAtkins> | i'm busy this afternoon and not reviewing the chatroom, shitpost away since i won't see it until tomorrow |
| 20:40 | <shu> | have y'all considered using identifiers followed immediately by は |
| 20:41 | <TabAtkins> | that's part of the ident production shu |
| 20:41 | <shu> | shit, you're right |
| 20:41 | <shu> | i will walk away head hanging in shame |
| 20:41 | <TabAtkins> | you can already ha your day away |