00:09:27  * araijoined
01:12:57  <caitp>`(new class { #x; m(o) { if (!o) o = this; return eval("o.#x;"); } }).m()` would throw a SyntaxError right, because direct (or not) eval() and CreateDynamicFunction can't reference private names from an outer PrivateNameEnvironment, right
01:15:17  <caitp>but it wuold be a SyntaxError when the eval() is called, not when the top level script is parsed
01:18:27  <caitp>basically private names outside the eval can never be referenced by stuff inside an eval?
01:19:52  <caitp>but what about `class C { #x; constructor() { return eval("new class extends C { get x() { return this.#x; } }"); } }` or something like that
01:21:58  <caitp>apparently that's more of a stack overflow... but a similar thing to that would work
01:22:07  <caitp>or fail
01:22:09  <caitp>lets see
01:25:28  * jwaldenquit (Quit: back later maybe)
01:26:57  <caitp>https://jsfiddle.net/af62w5gg/ basically that
01:27:15  <caitp>gsathya: littledan: ^ if you guys have an opinion
01:29:31  <caitp>it looks like per the current proposal, it explicitly should be a SyntaxError
01:29:34  <caitp>fair enough
01:35:16  <caitp>I don't see a test262 test matching that pattern in the collection checked into wekit atm, might eb good to add one
01:36:00  <devsnek>i thought subclasses didn't inherit private symbols
01:36:16  <Bakkot>caitp: eval is meant to have access to outer PrivateNames per https://github.com/tc39/proposal-private-fields/issues/47
01:36:36  <caitp>Bakkot: this is explicitly stated in the proposal already
01:36:54  <Bakkot>and there should be a test that this is the case
01:36:55  <caitp>but, v8 doesn't behave correctly, and afaik there's no test262 coverage for it yet
01:37:17  <Bakkot>I can believe there's a coverage hole for sure
01:37:31  <devsnek>i wouldn't expect any engines to behave "correctly" yet
01:37:33  <Bakkot>I had some in my initial V8 implementation way back when, but I assume those didn't all get ported
01:40:07  <caitp>it looks like v8 is taking the dynamic private name lookup path in that example, instead of throwing when it sees that #x is referenced in the class declared in the eval() but the private name isn't declared in that class
01:42:27  <caitp>ah, if you remove the definition of #x, then eval() reports it as invalid, so the eval() still sees the lexical #x and that's the only thing being used to determine if it's valid or not
01:42:39  <caitp>neato.
01:42:57  <devsnek>hey caitp can i pick your brain a bit in #v8
01:43:05  * keith_millerjoined
01:43:06  <caitp>it would be simpler if we spec that, but i'm happy either way
01:55:43  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:05:08  * keith_millerjoined
02:08:17  * diervo_joined
02:08:40  * littledan_joined
02:09:00  * devsnek_joined
02:09:17  * tobie_joined
02:09:37  * keith_millerquit (Client Quit)
02:10:19  * spectranaut_joined
02:12:42  * alex3joined
02:12:50  * devsnekquit (Ping timeout: 256 seconds)
02:12:51  * diervoquit (Ping timeout: 256 seconds)
02:12:51  * littledanquit (Ping timeout: 256 seconds)
02:12:51  * tobiequit (Ping timeout: 256 seconds)
02:12:51  * ambalekquit (Ping timeout: 256 seconds)
02:12:52  * saulh[m]quit (Ping timeout: 256 seconds)
02:12:52  * spectranautquit (Ping timeout: 256 seconds)
02:12:53  * diervo_changed nick to diervo
02:12:53  * littledan_changed nick to littledan
02:12:56  * tobie_changed nick to tobie
02:12:57  * devsnek_changed nick to devsnek
02:16:49  * M-IvanSanchezquit (Ping timeout: 246 seconds)
02:35:03  * jwaldenjoined
02:44:28  * keith_millerjoined
02:59:02  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:39:19  * keith_millerjoined
03:44:58  * jmdyckquit (Remote host closed the connection)
04:47:49  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:08:19  * keith_millerjoined
05:18:35  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
06:14:53  <littledan>Hey, as bakkot says, eval is supposed to support reading and writing private fields. Where do you see the spec doing something different?
06:15:08  <littledan>We should probably add these test262 tests and fix up the spec test
07:04:48  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:26:21  * isHavvyjoined
08:29:24  * Havvyquit (Ping timeout: 260 seconds)
08:46:40  * saulh[m]joined
08:52:55  * M-IvanSanchezjoined
09:04:13  * araiquit (Remote host closed the connection)
09:38:52  * saulh[m]quit (Ping timeout: 246 seconds)
09:38:56  * M-IvanSanchezquit (Ping timeout: 256 seconds)
10:16:53  * saulh[m]joined
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:51:04  * araijoined
10:52:52  * araiquit (Remote host closed the connection)
11:00:09  * AtumTjoined
11:01:14  * araijoined
11:19:39  * M-IvanSanchezjoined
11:30:09  <littledan>what's missing is for the private name environment to be properly propagated through the lexical scoping mechanism... that was working before, back when we just hacked it onto the variable environment, but now it needs to be fixed up. See https://github.com/tc39/proposal-class-fields/issues/40
11:30:37  <littledan>though the old phrasing had other problems, e.g., when it comes to with
11:56:32  * linclarkquit (Ping timeout: 256 seconds)
11:59:29  * linclarkjoined
12:41:32  * seishunjoined
12:42:24  <seishun>hey, are there any TC39 delegates here or anyone who knows a TC39 delegate who might be interested in championing https://github.com/tc39/proposal-bigint/issues/137?
12:45:35  <devsnek>I wouldn't expect trying to put a bigint into a number typed array to work at all
12:50:28  <Domenic>Agreed, this is a pretty clear case of "doctor it hurts when I do this"
12:53:57  * jmdyckjoined
12:54:32  <seishun>Domenic: what do you mean by that?
12:55:58  <Domenic>The patient says, "Doctor, it hurts when I do this," then twists his body in a bizarre way. The doctor says, "Then don't do that."
12:57:11  <Domenic>(This is part of some old comedy routine, but has become a shorthand used in technical circles.)
14:56:20  * seishunquit (Read error: Connection reset by peer)
15:01:26  <caitp>littledan: I actually think eval being able to read/write private names declared outside the eval is a pretty bad idea, and it’s problematic for other reasons
15:03:47  <caitp>especially if you want to have the AllPrivateNamesValid rules
15:05:47  <caitp>but, the modification to eval() and CreateDynamicFunction also explicitly violates the AllPrivateNamesValid rule if they use a name outside of a class declaration which declares it in the eval()
15:06:12  <caitp>so, the spec explicitly does not allow it atm
15:06:22  <caitp>why are you saying it does?
15:19:03  <caitp>oh hang on, I see what you're getting at
15:20:05  <caitp>I would say "remove step 7 and 8 in the modified eval() algorithm to avoid a kind of injection attack, that only makes sense"
15:21:26  <caitp>CreateDynamicFunction doesn't have that modification though, so it is a SyntaxError in new Function(...) --- I guess I assumed it was consistent between the two
15:21:33  <caitp>the fact that it's not consistent is also kind of bad
15:45:27  * seishunjoined
16:05:01  * seishunquit (Read error: Connection reset by peer)
16:12:46  * seishunjoined
16:46:04  <littledan>Yeah, I mean I agree with you on the design point. That's why I argued against allowing private fields access from eval in committee. But, the committee went the other way
16:46:41  <littledan>You're probably right about there being spec bugs here, I need to look at it more closely
17:14:56  <ljharb>could private fields be made to work inside Function
17:14:56  <ljharb>?
17:17:47  * keith_millerjoined
18:20:06  * saulhquit (Remote host closed the connection)
18:58:55  <gsathya>caitp: The jsfiddle you posted is not a SyntaxError looking at the spec and V8 behaves correctly. I don't know about test262 tests, but I have V8 tests for this
19:07:13  <caitp>gsathya: it should be though
19:07:15  <caitp>that its not is bad
19:10:03  <caitp>like, it is a bad design
19:12:46  <caitp>i explained why up there
19:18:49  * jwaldenjoined
20:05:39  <Bakkot>ljharb: function is like indirect eval, no? it doesn't see variables from the calling scope. so it definitely shouldn't see private names.
20:07:50  <Bakkot>caitp: not sure I understand the argument that it's a bad design
20:08:56  <Bakkot>indirect eval should not have access to private names, direct eval should; this is consistent with access to anything else that's closed over
20:31:51  <ljharb>Bakkot: ah yeah good call
20:33:21  * seishunquit (Ping timeout: 240 seconds)
20:44:16  <caitp>Bakkot: because its room for injected stuff to access private state, it breaks guarantees
20:44:24  <caitp>not a fan of that
20:57:16  <Bakkot>caitp: if you're not sanitizing code passed to a direct eval, you have bigger problems
20:57:36  <Bakkot>I don't think it breaks guarantees any more than the fact that a direct eval can access closed-over variables
20:57:59  <Bakkot>if you want guarantees, you need to be able to reason about what you're passing to eval
20:58:37  <caitp>yeah, OR, the primitive could be just not exposing this
20:58:43  <caitp>because like, there's no benefit to it
20:59:25  <Bakkot>there's benefit - it makes the mental model more consistent
20:59:31  <caitp>how
21:00:24  <Bakkot>currently the model for how privacy works with private fields is that the names are lexically scoped, so code has access to the field iff it has access to the lexical scope in question, just like for closed-over variables
21:00:33  <Bakkot>this implies they can be used from a direct eval
21:00:47  <caitp>eval has behaved kind of stupidly forever, keeping consistency with that badness isn't really improving things, it's just making new things worse
21:01:13  <caitp>a simpler model is like "eval code can't use private names, period"
21:01:19  <caitp>which would be awesome
21:01:45  <caitp>or at the very least "can only use private names declared in PNEs which occur within the eval"
21:02:24  <Bakkot>That's strictly less simple
21:02:24  <Bakkot>that's precisely the above mental model, plus an epicycle
21:02:39  <caitp>how is that less simple
21:03:04  <Bakkot>Because now it's "currently the model for how privacy works with private fields is that the names are lexically scoped, so code has access to the field iff it has access to the lexical scope in question, just like for closed-over variables. EXCEPT ALSO they're opaque to direct eval, for some reason."
21:03:34  <caitp>eval'd code isn't strictly in the same lexical scope
21:03:38  <caitp>that string can come from anywhere
21:03:45  <Bakkot>the model is no longer "lexical scope". now it's "lexical scope, and we decided to make it work differently for direct eval"
21:04:01  <Bakkot>for the purposes of JS code, direct eval'd code is in the same lexical scope.
21:04:12  <Bakkot>that's what the "direct" part means.
21:04:13  <caitp>or we can just stop calling it "lexical scope" and just make PNEs behave sort of like lexical scope
21:04:28  <caitp>"it's lexical, but better than ES2015 lexical"
21:04:55  <Bakkot>sure, we can, but then we've introduced a new kind of scoping to the language.
21:05:29  <caitp>I mean, not really
21:05:44  <caitp>it's just a stricter meaning of lexical
21:06:07  <Bakkot>stricter implies different
21:06:27  <cloudshu>i prefer not special casing direct eval for private names as well
21:06:27  <caitp>"it's the same but with fewer bad ideas"
21:07:18  <cloudshu>is the desire so there's no need to implement by-name access for private names?
21:07:28  <cloudshu>and everything can be by-slot or whatever with all the lookups resolved ahead of time?
21:09:03  <caitp>i'm not 100% sure what you mean -- you mean like instead of doing a dynamic search for the name, it's statically known?
21:09:28  <cloudshu>yes
21:09:58  <caitp>it's probably easier to do that yeah
21:10:00  <cloudshu>i'm asking if you want private names to be invisible to direct eval for implementation reasons, or because you think it's gross
21:11:08  <caitp>hopefully the dynamic lookups can be eliminated during optimization anyways, but that's not really the reason for not liking it
21:11:29  <cloudshu>okay
21:11:31  <caitp>way I see it, eval code isn't "really" lexical, even for direct eval, it shouldn't be treated as lexical
21:12:16  <cloudshu>ah interesting
21:12:24  <cloudshu>i've always considered direct eval to be exactly lexical
21:12:33  <caitp>well I mean the spec considers it that wy
21:12:34  <caitp>way
21:12:46  <caitp>but the actual eval'd source isn't guaranteed to be lexical
21:12:51  <cloudshu>eval in general isn't really lexical, to be sure, but direct eval remains so
21:12:56  <cloudshu>how so? because vars might not escape sometimes?
21:13:22  <caitp>because the string could come from somewhere else
21:13:24  <caitp>could come from user input
21:13:28  <caitp>could come from untrusted stuff
21:13:50  <caitp>so because of that, I don't think it should be able to do anything with lexical variables surrounding the direct eval
21:13:54  <caitp>sanitized or not
21:14:17  <cloudshu>oh, not lexical in that the eval'd source isn't in-situ in the scope in which it's evaluated
21:15:29  <cloudshu>i think the mental model of direct eval is to eval something in the current lexical scope
21:15:37  <cloudshu>making private names an exception here would be very surprising imo
21:15:47  <caitp>i wouldn't be surprised
21:15:49  <cloudshu>and i don't mean the mental model for the spec, i mean how people use it
21:16:19  <caitp>in fact, I'm pretty sure most people don't really distinguish between direct and indirect eval
21:16:31  <cloudshu>really?
21:16:50  <cloudshu>actually who uses indirect eval anyhow
21:20:09  <ljharb>i use it
21:20:18  <ljharb>`Function` is the only way to featuretest syntax
21:20:27  <ljharb>(the only way that’s not eval, and eval is terrible)
21:20:46  <caitp>I've seen people use it by accident when I was working on angularjs, and use it on purpose for sketchy reasons
21:21:53  <cloudshu>i see
21:30:27  <caitp>statically resolving private names would be nice though
21:30:29  <caitp>no doubt
21:30:58  <Bakkot>as long as there's no direct evals, which everyone has to check for anyway, you can still do that
21:31:55  <caitp>not worth having 2 paths for it imo
21:32:13  <caitp>not in baseline
21:35:18  <cloudshu>the path already has to exist for basically everything else, though
21:36:18  <caitp>we don't really have a path converting dynamic loads into constants in baseline
21:36:29  <caitp>at least, last I checked
21:37:24  <caitp>and eliminating scope resolution and stuff, having multiple paths for it seems pretty flaky
22:07:11  <cloudshu>that's a parser decision
22:07:16  <cloudshu>i don't know how ignition works, it's vregs, right?
22:07:27  <cloudshu>but the decision whether a local or something can even go into a vreg must be based on the presence of eval
22:40:40  * not-an-aardvarkjoined
22:40:41  * keith_millerquit (Read error: Connection reset by peer)
22:42:51  * keith_millerjoined
22:49:23  * araiquit (Ping timeout: 276 seconds)
22:53:45  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:04:46  * keith_millerjoined
23:20:13  * AtumTquit (Remote host closed the connection)
23:30:58  <caitp>I'm not implementing it in v8 --- making the decision, either at parse time or at codegen time, creates a complex decision, which is kind of annoying to make for something not strictly necessary
23:31:38  <caitp>but again, it's not really a "change it for easier implementation" thing, it's just a "don't expose private information to arbitrary code" thing
23:35:19  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:37:06  * keith_millerjoined
23:59:17  * araijoined