00:06:16  * cybaijoined
00:07:36  * keith_mi_joined
00:10:48  * cybaiquit (Ping timeout: 255 seconds)
00:12:17  * keith_mi_quit (Ping timeout: 246 seconds)
00:15:49  * keith_mi_joined
00:21:18  * keith_mi_quit (Ping timeout: 245 seconds)
00:51:19  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
01:07:13  * keith_mi_joined
01:23:27  * keith_mi_quit (Ping timeout: 240 seconds)
01:45:52  * cloudshuquit (Quit: Connection closed for inactivity)
01:54:52  * cybaijoined
02:06:47  * AtumTquit (Quit: AtumT)
02:28:45  * keith_mi_joined
03:21:20  * cybaiquit (Remote host closed the connection)
04:01:21  * cybaijoined
04:05:45  * cybaiquit (Ping timeout: 246 seconds)
04:06:41  * jmdyckquit (Remote host closed the connection)
04:35:00  * Jessidhiaquit (Disconnected by services)
05:07:13  * Jessidhiajoined
05:25:38  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:02:24  * cybaijoined
06:07:12  * cybaiquit (Ping timeout: 255 seconds)
06:33:20  * keith_mi_joined
07:11:58  * kpattichajoined
07:38:05  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:58:16  * mgoljoined
08:03:13  * cybaijoined
08:03:30  * keith_mi_joined
08:04:30  * keith_mi_quit (Client Quit)
08:07:55  * cybaiquit (Ping timeout: 258 seconds)
08:54:40  * keith_mi_joined
09:32:28  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:04:16  * cybaijoined
10:08:37  * cybaiquit (Ping timeout: 244 seconds)
11:03:09  * jmdyckjoined
11:40:57  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:41:47  * mgoljoined
12:04:59  * cybaijoined
12:06:02  * gibson042quit (Quit: Leaving.)
12:09:26  * cybaiquit (Ping timeout: 246 seconds)
13:18:14  * howdoiquit (Quit: Connection closed for inactivity)
13:41:07  * cybaijoined
13:43:13  * howdoijoined
13:45:39  * cybaiquit (Ping timeout: 258 seconds)
13:46:12  * cybaijoined
13:58:55  <devsnek>rwaldron: seems like there might be an issue with the jsc runner? https://gc.gy/23732912.png
14:25:04  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:25:44  * mgoljoined
15:07:42  * cybaiquit (Remote host closed the connection)
15:08:13  * cybaijoined
15:13:22  * Nimelrian_joined
15:35:17  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:36:57  * keith_mi_joined
15:37:27  * keith_millerquit (Ping timeout: 240 seconds)
16:14:43  * kpattichaquit (Quit: Leaving)
16:23:28  * cloudshujoined
16:28:52  * cybaiquit (Remote host closed the connection)
17:05:00  * cybaijoined
17:09:36  * cybaiquit (Ping timeout: 255 seconds)
17:13:11  * AtumTjoined
17:46:26  * Nimelrian_quit (Ping timeout: 258 seconds)
18:06:19  * keith_millerjoined
18:12:35  * cybaijoined
18:17:13  * cybaiquit (Ping timeout: 276 seconds)
18:28:23  * cybaijoined
18:32:50  * cybaiquit (Ping timeout: 250 seconds)
19:05:55  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:16:05  * AtumTquit (Ping timeout: 258 seconds)
19:16:41  * AtumTjoined
19:23:50  * AtumTquit (Read error: Connection reset by peer)
19:24:12  * keith_millerjoined
19:24:51  * AtumTjoined
19:45:25  <caitp>is there an annex B or web compat reason why all vms seem to ignore changes to property `enumerable`-ness during for-in loops?
19:52:25  <caitp>e.g. https://jsfiddle.net/y6sdgm2b/
20:00:14  <caitp>I mean I know it's "undefined", except that afaict all the vms match, but the way they match is incongruent with the example implementation in the spec
20:03:34  * mgoljoined
20:16:35  * AtumTquit (Quit: AtumT)
20:28:38  <Bakkot>caitp: I don't think that's actually true; Chakra matches the spec
20:28:49  <Bakkot>also XS, though I dunno if we're counting it
20:29:06  * cybaijoined
20:29:10  <Bakkot>I have that case in https://github.com/bakkot/for-in-exploration/blob/master/made-enum.js
20:29:20  <caitp>I was thinking "browsers", and I dunno if chakra really counts there anymore
20:29:37  * gibson042joined
20:30:01  <Bakkot>anyway, in reseaching this a while back I couldn't find any references to people depending on that behavior
20:30:17  <caitp>the behaviour of the engines I've tried (v8/jsc/sm) seem pretty consistent, so I thought it would be good if the spec actually reflected it
20:30:19  <Bakkot>unlike some other genuinly interop semantics: https://github.com/bakkot/for-in-exploration#real-constraints
20:30:59  <Bakkot>I am intending to bring to the committee a proposed spec text for some interop semantics at the June meeting
20:31:05  <Bakkot>though that will depend on me actually running it
20:31:35  <Bakkot>and also, since Chakra differs here (and that mattered when I was first doing this), I did not consider this particular case to be within the interop semantics
20:32:02  <Bakkot>(s/actually running/actually writing/)
20:33:27  * cybaiquit (Ping timeout: 246 seconds)
20:33:46  <caitp>interesting, you've done a lot more work on it than me
20:34:39  <Bakkot>I'm guessing this is coming from you following up one of my JSC bugs which came out of this process?
20:35:04  <Bakkot>if there's some other for-in stuff you're working on I'd be interested in following along
20:38:49  <caitp>no it is still your filed bugs --- the JSC behaviour and all the matching VMs seem to pre-filter enumerable properties at the start of the loop, and then do another [[GetOwnProperty]] for each key to see if it exists (but ignore the DontEnum-ness)
20:39:13  <caitp>so it's a little awkward to get the expected semantics
20:41:16  <caitp>its' weird for proxies because you observably do [[GetOwnProperty]] for each key twice, once during the pre-filtering and again during the loop, which based on what the spec illustrates as an example implementation, shouldn't happen
20:45:37  <Bakkot>so, since you're looking at this, can I ask - my plan was to say that engines are required to implement the spec's semantics for proxies in particular
20:45:58  <Bakkot>with the thought that they'd just have a special case for proxies
20:46:03  <Bakkot>does that seem reasonable?
20:47:39  <Bakkot>(the other half of the plan was to somehow nail down the "normal" case - no proxies or other exotics, no prototype changes, no enumerability changes, no non-enumerable properties shadowing enumerable properties, etc - and then say that you can do whatever you want as long as it matches the spec algorithm in those cases, which all engines already do)
20:48:44  <caitp>in JSC's case it's doable, I don't know if I like them having different semantics since any difference would be observable (e.g. wrt changes to enumerability affecting keys that are handled in the loop)
20:51:01  <Bakkot>hm, yeah. my intent was to minimize the observable differences between engines, rather than between similar-ish cases on a single engine, but I don't know how to prioritize those.
20:51:14  <Bakkot>currently engines all behave radically differently when for-in'ing a proxy
20:52:10  <Bakkot>(the proxy-trapped test in the above repo illustrates this)
21:02:28  <caitp>I think https://gist.github.com/caitp/db5eae82a62b27d9e8ee9f7ab6b20a01 comes pretty close to what jsc does, I dunno if that exactly matches other engines
21:03:52  <caitp>in the proxy case
21:06:55  <Bakkot>no, not quite
21:07:08  <Bakkot>though that also doesn't match JSC, at least on my local copy
21:08:14  * howdoiquit (Quit: Connection closed for inactivity)
21:08:36  <Bakkot>that gist differs from other engines mainly in that no engine other than JSC will print a non-enumerable property which shadows an enumerable one
21:08:45  <caitp>you might not have r244330 locally
21:08:45  <Bakkot>i.e. JSC is unique in printing `x` in https://github.com/bakkot/for-in-exploration/blob/master/enumerable-shadowed.js
21:09:50  <caitp>yeah, I haven't done a lot of testing with the prototype object
21:13:34  <Bakkot>hm. just updated, now on v244563, but still seeing the same proxy traps hit for JSC
21:16:15  <caitp>right now upstream:
21:17:12  <caitp>if the proxy has no ownKeys handler, we do the normal [[GetOwnPropertyNames]] for the target object, and [[GetOwnProperty]] isn't run through the proxy
21:17:27  <caitp>if it does have the ownKeys trap, then...
21:20:04  <caitp>ownKeys is called, the returned object is converted into a list, configurable/extensible invariants are performed etc, and at the end, the list is re-filtered, kicking out DontEnum keys, before ever reaching the loop body
21:21:31  <caitp>then, in the loop, for each key returned from `ProxyObject::performGetOwnPropertyNames()`, the loop body is evaluated only if `Boolean([[GetOwnProperty]](proxy, key))` is true
21:22:06  <caitp>so there should be an ownKeys trap call, and 2 gopd trap calls per key, assuming "ownKeys" exists
21:22:30  <caitp>and no trap calls (except for the gopd done in the for-in loop) if it does not exist
21:25:04  <Bakkot>sounds about right. gets a little weirder in the presence of prototypes.
21:27:07  <Bakkot>other engines are consistent about only ever invoking gopd once per key, even when (as in spidermonkey) that leads to spec-prohibited behavior ( https://bugzilla.mozilla.org/show_bug.cgi?id=1486656 )
21:28:07  <Bakkot>i'd prefer that, if we spec behavior for proxies, we do it in such a way that gopd is invoked only once per property
21:31:49  * gibson042quit (Quit: Leaving.)
21:38:19  <caitp>v8 seems to follow your suggestions (ignoring anything wrt prototype shadowing), so for proxies, filtering is deferred until each loop iteration, and enumerability is checked there, but for non-proxies it's all pre-filtered
21:41:08  <caitp>it wouldn't be the worst thing if all impls matched that, but I think it's not great to have the inconsistent behaviour between proxies and non-proxies, so I'd be happier to just forbid pre-filtering when it's observable, and let turbofan/DFG/etc do it if they decide they can
21:41:31  <caitp>what's the worst that could happen
21:43:47  <Bakkot>I've been trying to avoid doing anything with the case where it's observable
21:44:07  <Bakkot>mostly because that would require engines to make changes for non-proxy cases, which historically has been... basically impossible
21:44:58  <Bakkot>sorry, for the case where it's observable without proxies; I have higher hopes for getting engines to change where proxies are involved
21:54:09  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:55:25  * keith_millerjoined
21:55:35  <Domenic>> Previous discussions (Yes, I have read every comment in every one of these threads.)
21:55:38  <Domenic>I love it
21:59:47  <devsnek>`proxy-trapped.js` is pretty crazy
22:00:55  <devsnek>nothing except engine262 and XS agree in proxy-trapped.js
22:03:21  <devsnek>lmao jsc has an abrupt completion in this what even
22:04:40  <Bakkot>wait, where?
22:05:27  <devsnek>Bakkot: https://gc.gy/23762126.png
22:05:50  <devsnek>x apparently doesn't get bound in the loop iteration
22:06:49  <devsnek>actually wait `loop: x` is there
22:06:56  <devsnek>i dunno
22:10:56  <Bakkot>devsnek: I think this might be an old eshost bug or something
22:11:01  <devsnek>oh
22:49:55  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:58:47  * gibson042joined
23:30:54  * cybaijoined
23:35:36  * cybaiquit (Ping timeout: 258 seconds)