00:00:29  * sebmarkbagechanged nick to sebmarkbage|away
00:10:34  * brabquit (Ping timeout: 264 seconds)
00:39:08  * AtumTquit (Remote host closed the connection)
02:14:48  * Fishrock123quit (Remote host closed the connection)
02:15:35  * sebmarkbage|awaychanged nick to sebmarkbage
02:22:41  * akirosequit (*.net *.split)
02:22:41  * caitpquit (*.net *.split)
02:25:12  * caitpjoined
02:27:44  * akirosejoined
02:34:09  * sebmarkbagechanged nick to sebmarkbage|away
02:34:43  * rbucktonquit (Quit: Connection closed for inactivity)
02:34:51  * sebmckjoined
02:37:15  * sgotoquit (Quit: Connection closed for inactivity)
02:47:02  * sebmarkbage|awaychanged nick to sebmarkbage
02:55:10  * sebmarkbagechanged nick to sebmarkbage|away
03:06:18  * Fishrock123joined
03:21:05  * sebmck_joined
03:21:17  * sebmckquit (Ping timeout: 255 seconds)
03:21:18  * sebmck_changed nick to sebmck
03:38:12  * Fishrock123quit (Remote host closed the connection)
03:49:52  * Fishrock123joined
04:10:09  * sebmckquit (Ping timeout: 248 seconds)
04:28:55  * jmdyckquit (Remote host closed the connection)
04:39:08  * sebmckjoined
04:40:13  * sebmckquit (Client Quit)
04:42:21  * sfinkquit (Ping timeout: 240 seconds)
04:44:28  * sfinkjoined
04:48:31  * sfinkquit (Remote host closed the connection)
05:04:42  * Fishrock123quit (Remote host closed the connection)
05:05:51  * Fishrock123joined
05:28:35  * Fishrock123quit (Remote host closed the connection)
05:28:54  * Fishrock123joined
05:29:21  * Fishrock123quit (Remote host closed the connection)
06:33:54  * Fishrock123joined
06:38:09  * Fishrock123quit (Ping timeout: 246 seconds)
06:44:13  * Fishrock123joined
07:12:26  <annevk>tschneidereit: where is the latest on typed objects?
07:14:22  <tschneidereit>annevk: currently waiting on wasm's requirements to become clear enough to usefully coordinate. I want to revive work on TOs sometime next year. Ideally H1, but not sure
07:19:30  <annevk>tschneidereit: kk, wycats and I were wondering if they would be useful in a future version of the DOMChangeList idea where we'd expose the underlying buffer/object
07:19:51  <annevk>tschneidereit: I take it they'd be generic and work on top of SAB too?
07:20:22  <annevk>oh well, prolly asking stuff too soon
07:20:58  <tschneidereit>annevk: I haven't spent much time investigating the implications of SABs, but AFAICT there's nothing fatal that would prevent that
07:32:12  * Fishrock123quit (Quit: Leaving...)
07:32:47  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
07:54:48  * cloudshuquit (Quit: Connection closed for inactivity)
09:23:19  <Bakkot>gsathya / aklein / other class field implementors: re: https://github.com/tc39/proposal-class-fields/issues/43, if we went with the current semantics, do you think it would be doable to give a good error message in this case, along the lines of "inherited static methods can't access static private fields when referred to using `this`; use [base class name].#field instead"
11:04:04  * AtumTjoined
11:04:31  * AtumTquit (Remote host closed the connection)
11:05:09  * AtumTjoined
11:25:10  * mylesborinsquit (Quit: farewell for now)
11:25:41  * mylesborinsjoined
12:21:47  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
13:11:04  * jmdyckjoined
16:30:27  * sebmarkbage|awaychanged nick to sebmarkbage
16:37:19  <tschneidereit>Bakkot: that would be possible, but wouldn't catch all cases. In theory you could have `let that = this; that.#field`, in which case an error message such as yours would be confusing at best, and certainly not possible as an early error
16:38:16  <tschneidereit>Bakkot: that last part seems most unfortunate to me: the early error would essentially be a lint. A pretty solid one, but still
16:39:20  * sebmarkbagechanged nick to sebmarkbage|away
18:21:51  <Bakkot>tschneidereit: in theory, but I think static private field accesses which looked like that would be *vanishingly* rare
18:22:18  <Bakkot>since (at least with the proposed semantics) there is exactly one object ever which you can refer to that field of
18:24:26  <Bakkot>in any case, you could still give an informative message i that case: the runtime can detect that B is a subclass of A, that A has private field #foo, and that you tried to access B.#foo, and that therefore your error was trying to access #foo on a subclass on A and should instead have written A.#foo
18:25:02  <Bakkot>(I would not like to see this as an early error, but I think an informative runtime error would help a lot if we go with the current semantics.)
18:26:05  <Bakkot>I know this would make ljharb sad, who does not want to have to repeat the class name, but it might be the best option.
18:30:31  <ljharb>Bakkot: so, i think it's fine for now, because we could still add a `static.` or `class.` later - but also, the spec doesn't mandate specific error messages, so i'm not sure that's automatically a solution
18:30:45  <ljharb>in general tho, static privates are just weird and not that useful, because you already get that with closures
18:39:38  <bterlson>tschneidereit: I don't know why I can't make you voice... can you try parting and joining?
18:43:02  <Bakkot>ljharb: *could* mandate specific error messages, but won't
18:43:33  <Bakkot>but it is kind of a solution; generally, "this will be confusing" is less of a concern if we think runtimes can in practice provide guidance in error messages
18:43:41  <ljharb>Bakkot: right, effectively the same thing (altho i'd be SUPER STOKED if we all agreed we could)
18:43:48  <ljharb>yeah true
18:52:56  <Bakkot>I guess I should say, I wouldn't want this to go in with the understanding that "we could still add a `static.` or `class.` later", because I think I would kill such a proposal
18:56:29  <ljharb>interesting, why?
18:57:05  * cloudshujoined
18:57:27  * gskachkovjoined
19:05:07  * msaboffjoined
19:12:44  <Bakkot>ljharb: syntax is expensive
19:12:47  <Bakkot>syntax is really expensive
19:13:07  <Bakkot>not in terms of blocking ourselves from using it for other things, just in terms of the size of the language
19:19:11  * caridyjoined
19:19:11  * caridyquit (Read error: Connection reset by peer)
19:19:34  * caridyjoined
19:21:18  * gskachkovquit (Quit: gskachkov)
19:21:50  * caridyquit (Remote host closed the connection)
19:22:01  * gskachkovjoined
19:22:24  * caridyjoined
19:47:03  <ljharb>meh, kind of
19:47:06  <ljharb>this is a metaproperty
19:51:26  <Bakkot>not really; more like `super.prop`, which isn't a metaproperty
19:51:44  <Bakkot>but even so, new metaproperties are also expensive
19:52:45  * jwaldenjoined
19:53:22  <ljharb>yeah true, it is more like super.prop
19:59:21  <tschneidereit>bterlson: bleh, I had, but apparently irccloud at some point forgot about that. Fixed now
20:03:20  * zkatjoined
20:04:13  <tschneidereit>Bakkot: I agree that a good error message goes a long way here. And I'm quite sure all engines should be able to give those
20:05:11  <tschneidereit>I don't think I fully agree with that class.#field would be all that expensive as syntax, but I do agree that it's not free and not to be introduced lightly just because we could
20:22:32  * gskachkovquit (Quit: gskachkov)
20:23:01  * gskachkovjoined
20:27:12  * gskachkovquit (Ping timeout: 248 seconds)
20:30:16  * gskachkovjoined
20:43:10  * gskachkovquit (Quit: gskachkov)
20:44:52  * gskachkovjoined
22:26:01  * not-an-aardvarkjoined
23:27:39  <aklein>Bakkot: I'm not of the opinion that the current specced semantics are disastrously bad, but I agree that a good error message would be nice
23:30:28  <ljharb>good error messages are nice regardless, and every engine likely has places to improve there :-)