00:06:22  * AtumTquit (Remote host closed the connection)
00:18:28  <caitp>gsathya: yes
00:25:47  <gsathya>excellent
01:57:40  * not-an-aardvarkjoined
03:38:29  * howdoijoined
04:13:51  * jmdyckquit (Remote host closed the connection)
05:53:35  * vikash-afkquit (Ping timeout: 240 seconds)
05:54:09  * bkstquit (Ping timeout: 256 seconds)
05:55:30  * bkstjoined
05:57:27  * vikash-afkjoined
06:03:58  <Bakkot>littledan / caitp: on reviewing that spec text again, that does create a pretty weird bit of observable semantics:
06:04:00  <Bakkot>`{ let f; class A extends (class {}) { x = (console.log(this), console.log(f())); constructor() { f = () => this; super(); } }; new A; }`
06:04:31  <Bakkot>the first console.log succeeds, the second fails with `this is not yet bound`
06:05:06  <Bakkot>(chrome actually gets this right; congrats gsathya.)
06:05:27  <ljharb>Bakkot: in your example, why would `f()` and `this` be different?
06:05:36  <Bakkot>anyway, not entirely sure if that's desirable. also would make a fun test262 test, if it's not one.
06:06:42  <Bakkot>ljharb: because class field initializers are effectively `.call`'d with the return value of super, so they can see the instance as `this`, but only _after they finish running_ is the `this` value within the constructor bound, which is what's necessary for `f()` to succeed
06:07:25  <Bakkot>littledan: to be clear, I'm not suggesting that anything be done about this, just wanted to note it
06:07:28  <ljharb>ah it's not tdz'd, it's simply "not bound" prior to super?
06:08:29  <littledan>Bakkot, yes, it would have those semantics. I think this is exactly what we were explicitly buying into when we said initializers had this in scope
06:10:13  <Bakkot>littledan: an alternative semantics could be `10. Perform ? thisER.BindThisValue(result). 11. Perform ? InitializeInstanceFields(result, F). 12. Return result.`
06:10:48  <Bakkot>which is 100% observably identical except that the call to `f` above would succeed.
06:11:06  <Bakkot>ljharb: tdz'd and "not bound" amount to the same thing; not sure what you're asking
06:11:55  <ljharb>Bakkot: wouldn't TDZd be like `const f = () => a; let a; f()` would work, meaning, that since `super()` binds `this`, `f()` would work - but by being not bound at all, f() always throws?
06:12:10  <littledan>Oh wait did we discusse this at some point?
06:13:28  <Bakkot>ljharb: no, the point is that the `let a` basically does not happen until _after_ the call to `f`, i.e., after all the initializers run
06:13:30  <Bakkot>littledan: no idea
06:14:01  <ljharb>Bakkot: ohhh right, so `super(); f()` would be fine, it's that `f()` runs inside an initializer that makes it throw?
06:14:10  <Bakkot>ljharb: exactly, yes.
06:14:22  <ljharb>got it
06:14:26  <ljharb>weird but makes sense
06:14:39  <littledan>I just don't have much of an option here. Honestly I don't think 'ah here's some crazy code, let's change the semantics' is such an awesome design strategy in general
06:14:57  <littledan>I don't think this edge case matters much
06:15:00  <Bakkot>lol
06:15:01  <Bakkot>yeah, agreed.
06:15:04  <littledan>And this is pretty superficial
06:15:22  <littledan>It's not about the deep meaning of what an object really is or something
06:17:42  <Bakkot>that said, I could imagine some engine noticing that their implementation could be more efficient if it were the other way around, which _if_ that happened I think it would be good to change the spec
06:18:06  <Bakkot>but that is purely hypothetical and I am not suggeting changing anything unless that unlikely hypothetical comes to pass; I just like highlighting weird edge cases
06:20:01  <littledan>I don't think this related to engine efficiency at all
06:20:18  <littledan>*relates
06:20:27  <littledan>This is just a one-off edge case
06:20:42  <littledan>This TDZ is a thing either way
08:12:04  * caridyquit (Read error: Connection reset by peer)
08:12:51  * caridyjoined
09:47:21  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:07:22  * caridy_joined
10:14:43  <littledan>I'd be fine with making the change, if anyone feels strongly. caitp , gsathya ?
10:14:45  * Effilryjoined
10:15:57  * caridyquit (*.net *.split)
10:15:59  * FireFlyquit (*.net *.split)
10:22:46  * Effilrychanged nick to FireFly
10:25:08  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:55:36  * AtumTjoined
13:13:16  * bradleymeckjoined
13:25:35  * jmdyckjoined
14:15:34  * jackhortonquit (Quit: Connection closed for inactivity)
14:26:08  * jmdyckquit (Ping timeout: 260 seconds)
14:27:16  * jmdyckjoined
14:28:32  * bradleymeckquit (Quit: bradleymeck)
14:41:45  * pandemquit (Ping timeout: 264 seconds)
14:45:45  * pandemjoined
14:54:11  * Bakkotquit (Ping timeout: 256 seconds)
14:59:36  * Bakkotjoined
15:28:57  * bradleymeckjoined
15:55:31  * caridy_quit (Remote host closed the connection)
15:56:21  * caridyjoined
16:47:03  <ljharb>littledan: which change; binding "this" before calling the initializers?
16:53:08  * Bakkotquit (Ping timeout: 260 seconds)
16:55:59  * Bakkotjoined
18:29:42  * bradleymeckquit (Quit: bradleymeck)
18:31:58  * bradleymeckjoined
18:48:06  <littledan>Yes
19:05:19  * JaseWjoined
19:05:20  * JaseWquit (Changing host)
19:05:20  * JaseWjoined
19:33:11  <ljharb>littledan: what would be the reasons *not* to make the change?
19:40:36  * AtumT_joined
19:43:22  * AtumTquit (Ping timeout: 260 seconds)
19:44:21  <littledan>I don't see a strong reason not to make the change, but the "conservative" default would be to just not make changes. Would the new semantics be significantly more reasonable-feeling?
19:51:53  <ljharb>it seems like it'd remove that tiny edge case and make "how this works in class fields" more consistent, but i might be missing some new conceptual impact that the change would have?
21:28:15  * jwaldenjoined
23:15:35  * JaseWquit (Ping timeout: 255 seconds)