00:15:33  * umpcquit (Ping timeout: 252 seconds)
00:23:36  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:25:50  * keith_millerjoined
00:51:50  * keith_millerquit (Read error: Connection reset by peer)
00:51:55  * keith_m__joined
01:14:26  * keith_m__quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:56:01  * keith_millerjoined
03:21:35  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:03:58  * jmdyckquit (Quit: Leaving.)
06:46:07  * howdoiquit (Quit: Connection closed for inactivity)
10:10:38  * AtumTjoined
11:00:26  * linclarkquit (Ping timeout: 260 seconds)
11:06:46  * linclarkjoined
12:42:16  * jmdyckjoined
13:34:29  * howdoijoined
14:08:22  * mgoljoined
15:00:17  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:35:33  <devsnek>littledan: what's the difference between `@thing(x)` and `@thing: x`
18:59:39  <littledan>devsnek: they're entirely different constructs?
18:59:55  <littledan>@thing(x) is already given semantics by the Stage 2 decorators proposal
19:00:05  <littledan>@thing: x would be able to be defined for something different
19:00:24  <devsnek>i must just be missing something
19:01:09  <devsnek>i read through the explainer but i couldn't figure out what it's actually adding except a different syntax
19:01:39  <devsnek>but what does the new syntax do
19:03:53  <devsnek>like `@use(tco)` vs `@use: tco`
19:08:57  <littledan>I mean, we'd have to define semantics for each thing
19:09:08  <littledan>it's a syntax error without a proposal to support it
19:09:21  <littledan>a separate proposal would define semantics for the built-in decorator and make it no longer a syntax error
19:09:36  <littledan>you're not supposed to read the whole thing on Twitter!
19:14:14  <devsnek>littledan: well you're proposing it, what are the semantics you're proposing
19:14:37  <littledan>I am proposing that this be a syntactic space for future features
19:14:56  <devsnek>is it not already?
19:15:00  <littledan>not that it have just one set of semantics ,but that we let a bunch of different features that need syntax use built-in decorators
19:15:18  <littledan>well, kinda, but I want to discuss together whether this makes sense, and see if we might align on this
19:15:26  <littledan>not for everything, but for places where it makes sense
19:15:51  <littledan>for example, it'd be nice to implement the general built-in decorator syntax in Babel and then you can just use a plugin to implement a new feature, rather than needing to hack the parser
19:16:02  <littledan>but, this only makes sense if the committee and community are somehow open to the idea
19:16:11  <devsnek>but like what's the difference between proposing that `@use(tco)` does something vs proposing that `@use: tco` does something
19:16:12  <littledan>so, that's why I want to ask them
19:16:33  <littledan>well, they are just different pieces of source code that we could assign different semantics to; I guess I don't understand the question
19:16:58  <littledan>I am proposing that @use(tco) have a certain meaning when put in front of a class, so that sort of "takes the space away" for built-in decorators there
19:19:48  * AtumTquit (Ping timeout: 246 seconds)
19:20:18  * AtumTjoined
19:38:26  * howdoiquit (Quit: Connection closed for inactivity)
19:40:41  * AtumTquit (Read error: Connection reset by peer)
19:40:57  * AtumTjoined
19:56:46  <devsnek>do i have to use string representation to get the high and low of a number in js
20:00:40  * mgoljoined
20:23:23  * AtumT_joined
20:23:50  * AtumTquit (Ping timeout: 250 seconds)
20:28:58  * AtumTjoined
20:30:26  * AtumT_quit (Ping timeout: 272 seconds)
21:06:54  <littledan>Would some other syntax be better, like @[use tco] or @{use: tco} or whatever?
21:07:05  <littledan>the syntax after @ is very restrictive, so we have a lot of options open to us
21:07:27  <littledan>or @@tco, or @#&^$tco, or...
21:17:15  <devsnek>littledan: is `use` a well known identifier, not something being looked up in scope?
21:17:31  <littledan>no, the thing before the colon is not looked up in the scope
21:17:33  <littledan>it's a syntax error
21:17:43  <littledan>it must be handled statically
21:17:52  <devsnek>ok that makes more sense
21:17:53  <littledan>otherwise, special built-in things would be impossible
21:18:01  <littledan>do you think there's something I can write in the explainer to clarify this?
21:18:40  <devsnek>🤷 probably just me being slow
21:18:56  <devsnek>in any case, i think `@` is probably a bad symbol in that case
21:20:10  <littledan>why's that?
21:20:22  <littledan>we don't really have a bunch of spare symbols...
21:20:41  <littledan>I was thinking of working towards the intuition that @ means modifying something, and # means integrity
21:22:36  <devsnek>well @ is already doing decorators
21:22:59  <devsnek>plus it leaves out the ability for built in things without an operand
21:23:30  <devsnek>for example, rust has a `#[test]`, without arguments
21:25:15  <littledan>well, # is private
21:25:46  <littledan>the document suggests that built-in things without arguments use something like @use: foo or @def: bar
21:25:55  <devsnek>i'm not saying `#` is better
21:25:59  <littledan>so, it's sort of two keywords
21:26:29  <devsnek>i feel like the solution would to grab well known decorators from somewhere
21:26:58  <littledan>I don't think that would lead to something capable of solving any of the use cases in the document. All of those require parse-time knowledge of what built-in decorator is being called
21:27:56  <littledan>the only alternatives I see are refraining from adding features (which is the best answer, if we shouldn't add the feature anyway) or more case-by-case syntax hacking when we do have something that we really want to add, as we've been doing.
21:30:44  <devsnek>i didn't see where it needing to be static came into play
21:33:37  <littledan>oh, I see
21:33:45  <littledan>maybe this could be made more clear?
21:33:58  <littledan>do you see how the use cases need to be static?
21:34:03  <devsnek>nope
21:34:10  <devsnek>all the individual examples look useful, but i don't see why they need to be static
21:36:55  <littledan>well, as an example of something we have, you know statically whether async functions are declared as async
21:36:55  <littledan>and this lets await be used inside of it
21:36:55  <littledan>for tail calls, this needs to be static so that the right interpreter bytecode can be defined
21:38:29  <devsnek>oh if you put the tco thing on the actual return
21:39:01  <devsnek>what if decorators can decorate a LeftHandSideExpression
21:41:18  <littledan>well, that would have grammar difficulties, as described in the explainer
21:42:12  <littledan>see https://github.com/littledan/proposal-built-in-decorators#no-support-for-decorating-arbitrary-expressions
21:48:45  <devsnek>well that's assuming you use the colon syntax
21:49:06  <devsnek>actually i guess `@x y` is still ambiguous :(
21:49:24  <littledan>Yeah, we need something more than that
21:49:34  <devsnek>btw for tco, i'd extend the return grammar
21:49:42  <devsnek>`return tail fn()` or something
21:49:49  <littledan>that has ASI hazards
21:49:56  <littledan>people weren't happy about any of the grammars we thought of
21:50:07  <littledan>there are also issues where it should be available within a ternary or ||, it's complicated
21:50:20  <devsnek>decorating return is kinda ugly though
21:50:42  <devsnek>you know rust kinda got this right by surrounding it in []
21:50:51  <devsnek>`@[builtin()]` done
21:51:01  <littledan>so, I'm OK with it if some of these examples don't make sense, this is more like an idea for more investigation
21:51:13  <littledan>yeah I'd be up for @[], though maybe it's confusing that it's array-like
21:51:18  <devsnek>actually surrounding it with brackets is kinda nice
21:51:26  <devsnek>since the existing grammar only allows an identifier there
21:51:31  <devsnek>clear separation 👌
21:53:26  <littledan>https://www.irccloud.com/pastebin/BDNJ1jk7/
21:54:22  <devsnek>👍
21:54:22  <littledan>FWIW, @[tuple] [1, 2, 3] would be pretty weird
21:55:00  <devsnek>any matching characters work in theory
21:55:45  <littledan>@/*<< tuple >>*/ [1, 2, 3]
21:56:19  <devsnek>👌
21:57:13  <littledan>OK, I'll think more about syntax
21:57:20  <littledan>it does seem useful to have a well-delimited beginning and end
21:57:34  <littledan>it just risks adding some more noise
22:13:05  * keith_millerjoined
22:19:54  <littledan>yeah, I'm getting more and more convinced that @[] is better than @:. This could be something to bikeshed about at the TC39 meeting
22:21:05  * AtumTquit (Quit: AtumT)
23:01:34  * Havvyquit (Ping timeout: 250 seconds)
23:01:41  * isHavvyjoined
23:06:14  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:21:46  * isHavvyquit (Ping timeout: 246 seconds)
23:23:04  * Havvyjoined