00:09:38  * bradleymeckquit (Quit: bradleymeck)
00:13:07  * AtumT_joined
00:15:59  * AtumTquit (Ping timeout: 265 seconds)
00:25:49  * AtumTjoined
00:27:41  * AtumT_quit (Ping timeout: 268 seconds)
01:06:29  * AtumTquit (Remote host closed the connection)
02:04:25  * bradleymeckjoined
02:19:19  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:32:07  * keith_millerjoined
02:35:31  * bradleymeckquit (Quit: bradleymeck)
03:12:07  * bradleymeckjoined
03:25:36  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:34:07  * keith_millerjoined
03:54:54  * bradleymeckquit (Quit: bradleymeck)
04:08:08  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
04:11:59  * keith_millerjoined
04:23:10  * caridyquit (Remote host closed the connection)
04:23:37  * caridyjoined
04:51:48  * jmdyckquit (Remote host closed the connection)
04:56:27  * jwaldenquit (Ping timeout: 260 seconds)
05:12:22  * srl295quit (Quit: Connection closed for inactivity)
05:19:13  * jwaldenjoined
05:26:12  * caridyquit (Ping timeout: 260 seconds)
07:17:51  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:52:27  * keith_millerjoined
07:53:56  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
08:56:28  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:34:39  * gskachkovjoined
09:53:04  * keith_millerquit (Quit: Textual IRC Client: www.textualapp.com)
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:42  * mylesborinsjoined
11:51:34  * Havvyquit (Ping timeout: 268 seconds)
11:54:35  * Havvyjoined
12:00:03  * tobiequit
12:00:36  * tobiejoined
12:03:34  * dhermanquit
12:03:49  * dhermanjoined
12:05:56  * Domenicquit
12:06:13  * Domenicjoined
13:13:48  * gibson042quit (Ping timeout: 240 seconds)
13:37:36  * bradleymeckjoined
13:39:25  * AtumTjoined
13:43:13  * bradleymeckquit (Quit: bradleymeck)
13:45:17  * jmdyckjoined
14:59:43  * bradleymeckjoined
15:00:38  * bstorozquit
15:00:51  * bstorozjoined
15:02:22  * ljharbquit
15:03:14  * ljharbjoined
15:30:41  * keith_millerjoined
15:32:30  * littledanquit
15:32:49  * littledanjoined
15:44:33  * gskachkovquit (Ping timeout: 248 seconds)
15:48:38  * caiolimaquit
15:48:54  * caiolimajoined
15:57:08  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:31:09  * AtumT_joined
16:34:15  * AtumTquit (Ping timeout: 265 seconds)
16:49:17  * gskachkovjoined
16:58:18  * gskachkovquit (Quit: gskachkov)
16:58:33  * jmdyck1joined
16:58:38  * jmdyckquit (Ping timeout: 276 seconds)
17:01:01  * gskachkovjoined
17:12:33  * jwaldenjoined
17:22:02  * bradleymeckquit (Quit: bradleymeck)
17:50:39  * keith_millerjoined
18:07:33  * caridyjoined
18:08:28  * gskachkovquit (Quit: gskachkov)
18:14:18  * gskachkovjoined
18:15:55  * gskachkovquit (Client Quit)
18:26:01  * bradleymeckjoined
18:28:33  * keith_millerquit (Remote host closed the connection)
18:33:10  <littledan>hey, I'm wondering what people here think of Ron Buckton's proposal to add static blocks to classes, as part of the "static class features" proposal. Very clear writeup with him, with examples, at https://github.com/tc39/proposal-static-class-features/issues/23
18:35:12  * keith_millerjoined
18:42:00  <Domenic>The fact that they escape the block just seems a little fatal to me
18:43:17  <Domenic>Oh this is just static blocks
18:43:27  <Domenic>Not declarations in a static block being accessible in the class
18:46:49  <littledan>right, they don't escape the block
18:46:57  <littledan>you can leak things from them, though
18:49:11  <bradleymeck>littledan: i'm curious to other things like if the same idea can apply to async initialization of modules. these blocks should never be async for class initializations though
18:49:32  <littledan>bradleymeck: I wasn't thinking of inserting async static blocks, no
18:50:02  <littledan>bradleymeck: Do you think we need to think through how it would apply to modules to apply it to classes?
18:50:41  <bradleymeck>littledan: unclear, I feel that you don't need to but it has a similar use case at least conceptually to me
18:51:02  <littledan>well, this is sort of analogous to imperative statements at the top level of a module, I think
18:53:47  <bradleymeck>littledan: I would agree
18:54:18  <bradleymeck>but since ESM initialization sometimes wants to be async and there are 2 discrete instantiate and evaluate points you would have more work to go through that
18:54:38  <bradleymeck>I think class static blocks might influence stuff for ESM, but no need to make sure they are in lock step
18:55:33  <littledan>I don't understand the difference between exporting a class with an async static block (which Ron didn't propose) and an await at the top level
19:08:17  <bradleymeck>littledan: depends on a bunch of UX, would a class with an async static block always initialize as a Promise rather than Function?
19:09:06  <littledan>bradleymeck: Do you think these decisions will come back and show us that we should've taken a particular other design for non-async static blocks?
19:09:20  <bradleymeck>doubtful
19:10:08  <bradleymeck>the only case which it might get weird is if you introduce async static blocks and it doesn't act the same as top level await (if it acts like Variant A, but top level await chooses Variant B)
19:11:03  <littledan>OK, I'll make sure to leave out async static blocks then
19:15:23  <bradleymeck>littledan: I do wonder if just having a static function that deletes itself wouldn't be similar thinking about this
19:15:25  * gskachkovjoined
19:17:43  <littledan>bradleymeck: Ron mentioned that in the thread, but I have a couple concerns. For one, deleting properties is a slow path in many implementations, and it feels weird to do these mutations to just get at a scope.
19:17:53  <littledan>that's a workaround you can do today, for sure
19:22:44  <bradleymeck>littledan: I guess decorators wouldn't need to do anything with these
19:22:52  <bradleymeck>anywho I'm rambling
19:23:30  <littledan>well, that's a design decision; we could make them decoratable
19:23:54  <littledan>what we'd need to decide upfront is whether to permit multiple, and whether they should be interspersed with something or run at the very end
19:26:05  <bradleymeck>i understand the interspersed vs end, but why would it be impossible to allow multiple ones later if we only allow 1 in first iteration?
19:26:32  <littledan>well, good point
19:28:17  <littledan>do you think it might be best to just add static public fields, and leave anything else for later?
19:29:00  <Bakkot>linclark: that is what I think, personally
19:29:11  * bradleymeckquit (Quit: bradleymeck)
19:29:13  <Bakkot>sorry, littledan
19:29:25  <Bakkot>(gotten too used to tab completion only needing two characters...)
19:32:15  <littledan>In the November 2017 meeting, there seemed to be a big request from the committee to make sure that things are all very well thought through, and not advance things peacemeal
19:32:26  <littledan>piecemeal
19:32:48  <littledan>that's why I've been hesitant to go with that option
19:48:54  <ljharb>for statics, i think starting with just public fields would be fine with me
20:17:18  * bradleymeckjoined
20:26:23  <bradleymeck>littledan: i'd push for later personally if we can, but i agree that planning ahead is always good (even if you scrap the plans)
20:35:27  <littledan>OK, sounds like to demonstrate that things are well-thought through, one way would be to write a bunch of explainer documents for all the possible follow-on proposals which will be consistent with the rest of the other class features
20:35:46  <littledan>or, probably, three of them: for lexical declarations in classes, static private, and static blocks in classes
20:35:56  <littledan>does anyone want to help out with writing these?
20:53:56  * fourthexjoined
20:55:51  <fourthex>I would like to propose that the import statement gets enhanced to include a filtering mechanism like require-shield on npmjs.org. This will increase developers confidence in using 3rd party modules.
20:57:03  <bradleymeck>fourthex: define "filtering"
20:57:07  <bradleymeck>do you just mean integrity checks?
20:57:51  <fourthex>When you require (import) another module, you can specify which modules that module are allowed to import.
20:58:29  <bradleymeck>fourthex: i'd be hesitant to do that in TC39, also would want integrity checks to do that not just by name
20:58:53  <fourthex>What do you mean by integrity checks?
21:02:02  <bradleymeck>fourthex: code signing of some nature, like https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
21:02:35  <bradleymeck>even if we ban modules by a specific name people can just rename them / put them into `data:` / `blob:` URLs etc.
21:02:58  <ljharb>fourthex: that sounds like a terrible idea; that should be an internal implementation detail of the thing you import.
21:03:37  <ljharb>also i could get around that by just copy-pasting all the code i wanted into my module; then you'd get no security benefit at all
21:04:15  <bradleymeck>ljharb: we do need some form of meta data passing in the import syntax but I agree that the actual details are probably best left to hosts which might have different trust/signing mechanisms
21:04:47  <ljharb>i think that limiting what an import can import would be just as bad an idea as limiting what functions a function can call.
21:05:29  <bradleymeck>in general code signing is not limiting what it can import, but verifying the imports content regardless of specifier
21:05:57  <bradleymeck>s/code signing/integrity checks/
21:06:55  <bradleymeck>this though leaks into some weird stuff like loader hook implications since replacing source text invalidates the signature
21:07:37  <ljharb>yeah code signing sounds fine
21:07:45  <Bakkot>yeah, this seems like a place for SRI or CSP
21:10:33  <bradleymeck>Bakkot: i'm less kean on CSP for same reason i dislike the crossorigin attribute on <script> tags, loading it in one place with the attribute and one without gets into weird races
21:11:14  <bradleymeck>CSP seems more like the provider (http server / fs / etc.) needs to store the data rather than the importer putting a flag on something it doesn't make
21:11:33  <bradleymeck>failing if it doesn't match seems safe though
21:11:42  <bradleymeck>keen*
21:17:48  <fourthex>But how do I as a developer feel confident that the 3'rd party module wouldn't do something terrible? Signing only secures that that code has not changed.
21:18:33  <fourthex>I am mostly worried about NodeJS scenario where the code can access the file system for instance
21:23:41  <ljharb>fourthex: you audit the code
21:23:45  <ljharb>including the entire dependency tree
21:24:15  <ljharb>and, you run the code in a sandboxed environment - so that instead of trying to prevent bad things, you make bad things have minimal consequence.
21:24:16  * gskachkovquit (Quit: gskachkov)
21:32:10  * gskachkovjoined
21:36:41  <fourthex>Yes. That is what we have traditionally done, but it means that every consumer will spend resources. If it makes a difference, Java actually has a similar mechanism with the policy files.
21:49:54  * gskachkovquit (Quit: gskachkov)
21:50:31  * gskachkovjoined
21:57:38  * fourthexquit (Quit: Page closed)
21:58:16  <bradleymeck>fourthex: but even with such specifier black/white listing you aren't auditing the content of the actual things so it doesn't really mean that your module didn't get malicious code
22:01:08  <bradleymeck>if express had a dependency become malicious or it became malicious you would still load it. if you review the content of express and/or use some 3rd party audit service with integrity checks you would be sure about the contents. and there are also other concerns about when content is verified. specifier naming doesn't help much without integrity to actually check the contents of
22:51:28  * devsnek_joined
22:58:41  * devsnekquit (Quit: ZNC 1.6.5 - http://znc.in)
22:58:41  * devsnek_changed nick to devsnek
23:31:00  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:37:08  * fourthexjoined
23:39:09  <fourthex>bradleymeck: Yes, I agree that it would need to be combined with an integrity check.
23:40:51  * not-an-aardvarkjoined