00:05:53  * M-IvanSanchezquit (Remote host closed the connection)
00:13:03  * M-IvanSanchezjoined
00:14:35  * tschneidereitquit (Ping timeout: 276 seconds)
00:16:51  * tschneidereitjoined
00:35:36  <Bakkot>I would definitely be happier with "no static private fields" than "static private fields only available to decorators"
00:41:14  * bradleymeckquit (Quit: bradleymeck)
00:47:36  * bradleymeckjoined
01:27:26  * bradleymeckquit (Quit: bradleymeck)
01:59:55  * bradleymeckjoined
02:32:24  * AtumTquit (Remote host closed the connection)
03:57:07  * bradleymeckquit (Quit: bradleymeck)
04:58:56  <ljharb>littledan: oh right, the "why" - in general i like decorators as a feature and would have multiple uses for it already, but i think it's much easier to reason about, explain, and use properly when it's effectively 1:1 sugar for something that can be done without a decorator.
05:33:07  * jmdyckquit (Remote host closed the connection)
07:13:16  * ebrynquit (*.net *.split)
07:13:37  * ebrynjoined
07:48:23  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:32:20  <serbang>how did you come up with the syntax `#field` for static private fields?
10:01:01  * gibson042quit (Quit: Leaving.)
10:51:49  * zkatquit (Read error: Connection reset by peer)
10:52:29  * zkatjoined
11:25:10  * mylesborinsquit (Quit: farewell for now)
11:25:40  * mylesborinsjoined
11:47:05  <littledan>serbang: It's the same as instance private fields. We need a token like # to syntactically differentiate private fields from ordinary properties, unfortunately
11:48:06  <littledan>would it be terrible if we said, "static private methods exist and static private fields don't exist in this proposal; we'll look into it with decorators but aren't making a decision now"?
11:48:46  <littledan>ljharb: It would be sugar for something that could be done already, namely decorators would desugar it into a private accessor pair
13:48:05  * jmdyckjoined
13:58:52  * AtumTjoined
14:26:09  * bradleymeckjoined
14:57:13  * gibson042joined
16:36:57  * jmdyckquit (Ping timeout: 240 seconds)
16:38:36  * jmdyckjoined
16:54:32  * Fishrock123joined
17:07:22  * srl295joined
18:05:48  * Fishrock123quit (Remote host closed the connection)
18:13:04  * Fishrock123joined
18:21:40  * not-an-aardvarkjoined
18:46:42  * jwaldenjoined
18:49:17  * bradleymeckquit (Quit: bradleymeck)
18:59:51  * cloudshujoined
19:05:05  * Fishrock123quit (Remote host closed the connection)
19:30:19  * bradleymeckjoined
19:46:01  <ljharb>littledan: 1) i don't think that would be terrible. 2) if that's the case (that i can achieve it, more or less ergonomically, without decorators) then great
19:51:38  * Fishrock123joined
20:44:13  * bradleymeckquit (Quit: bradleymeck)
21:15:14  * Fishrock123quit (Remote host closed the connection)
21:15:59  * Fishrock123joined
21:16:04  * Fishrock123quit (Remote host closed the connection)
21:16:47  * Fishrock123joined
21:16:52  * Fishrock123quit (Remote host closed the connection)
21:24:57  * bradleymeckjoined
21:52:13  * jackhortonquit (Quit: Connection closed for inactivity)
22:17:50  * Fishrock123joined
22:22:31  * Fishrock123quit (Ping timeout: 256 seconds)
22:36:22  * bradleymeckquit (Quit: bradleymeck)
22:53:37  * bradleymeckjoined
23:02:22  * Fishrock123joined
23:12:12  <littledan>heh, depend what you mean by "it" and "ergonomically"
23:18:47  * bradleymeckquit (Quit: bradleymeck)
23:21:32  <ljharb>lol
23:23:21  <littledan>ljharb: Well, that's a real question--what would your goal be here? And would it be "ergonomic enough" to have a private method that manually caches data in a lexically scoped variable declared outside the class?
23:23:55  <ljharb>i'd have to look at it to be sure, but yes, i think it would
23:50:53  * bradleymeckjoined