00:00:58  * not-an-aardvarkjoined
00:06:29  * araijoined
00:35:23  * AtumTquit (Remote host closed the connection)
00:35:41  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:43:53  * keith_millerjoined
01:46:30  * keith_millerquit (Client Quit)
01:54:23  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
04:55:15  * jmdyckquit (Remote host closed the connection)
05:39:17  * srl295quit (Quit: Connection closed for inactivity)
05:41:21  * howdoijoined
05:58:06  * saulh[m]quit (*.net *.split)
08:28:56  * saulh[m]joined
08:36:03  * saulh[m]quit (Ping timeout: 240 seconds)
08:36:35  * M-IvanSanchezquit (Ping timeout: 269 seconds)
09:08:10  * araiquit (Remote host closed the connection)
09:35:16  * M-IvanSanchezjoined
09:38:02  * saulh[m]joined
10:11:58  * araijoined
10:20:39  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:08  * mylesborinsquit (Quit: farewell for now)
10:25:38  * mylesborinsjoined
10:35:54  * AtumTjoined
12:46:51  * jmdyckjoined
15:06:27  <bradleymeck>interesting concern about lifetime detection with compositeKey and WeakRef combination https://github.com/bmeck/proposal-richer-keys/issues/3 , idk if anyone is interested but seems relevant to both
15:22:06  <Domenic>bradleymeck: I don't understand how this is different than if you did `let $a = { a }`?
15:23:46  <bradleymeck>that publicly exposes `$a.a` so your observation about the lifetime of `$a.a` is strongly held alive by `$a`, compositeKey isn't exposing the component parts for inspection. this might well be a non-issue, but something feels off
15:26:42  <Domenic>OK, then `let $a = new class { #x = a }`
15:28:07  <bradleymeck>I would say that is different, the main use case of compositeKeys seems to lean towards putting them into weakmaps, with `new class { #x = a }` I wouldn't think that the result has some intention of being in weakmaps just reading that
15:28:27  <bradleymeck>weak collections*
15:29:54  <bradleymeck>but the point is valid that it would expose `a`'s lifetime to whatever has a WeakRef of `$a`
15:30:11  <bradleymeck>so, going to stew on this, but might just be a non-issue
15:41:29  <caitp>if I'm module A, and I create a
15:41:46  <caitp>a composite key, and pass it to some module B, who decides to weak-ref it to observe collection of a component to the key
15:42:05  <caitp>then module B could figure out something about module A that wasn't supposed to be shared, maybe
15:46:50  <bradleymeck>caitp: but as Domenic pointed out, that is also true for anything private by indirect exposure: closured variables / private fields / etc.
15:47:35  <caitp>I don't think that's the same threat
15:48:18  <bradleymeck>caitp: can you expand on the difference
15:50:12  <caitp>the threat is observing the GC, not observing JS values
15:50:25  <caitp>or keeping them alive
15:50:43  <caitp>so I'm not sure how the indirect exposure matters
15:53:42  <devsnek>i think this is a non issue
15:56:41  <bradleymeck>caitp: you can recreate the scenario without compositeKey using all sorts of indirect exposure when something is kept alive by an internal value : https://gist.github.com/bmeck/e48f2151dcca8d5cb6553e6239a82851
15:57:16  <bradleymeck>the main interesting thing is that compositeKey is generally tailored to this scenario, not that it exposes something new
15:58:05  <devsnek>i think the issue here is the weak reference not the composite key
15:58:56  <caitp>I'm not entirely sure where the callback for the weakref is proposed, I'm not seeing it in https://github.com/tc39/proposal-weakrefs/blob/master/specs/spec.md
15:59:00  <caitp>i think
16:01:27  <bradleymeck>caitp: proposal has been shifting a bit, but it is in the factory now as `cleanup` https://github.com/tc39/proposal-weakrefs/blob/master/specs/spec.md#the-weakfactory-constructor
16:02:31  <devsnek>why would a callback for the thing we don't want people detecting be specified
16:04:23  <bradleymeck>devsnek: observing a direct value has a lot of nice use cases for system modelling and things like WASM / remote references / threaded resource cleanup /etc. , observing indirect values hasn't been discussed to my knowledge
16:07:11  <devsnek>indirect values are inherent with anything that owns anything else though?
16:07:16  <devsnek>like the class example
16:12:08  <caitp>if I'm module B, and module A gives me an instance of a class with some private member, and I decide to observe when that class gets GC'd, what does that give me
16:12:18  <caitp>that's not exposing anything really
16:13:13  <caitp>I mean I guess it says that whatever the associated value was isn't referenced anymore, but since I don't know anything about that value, does it matter?
16:13:30  <caitp>and does it even mean that?
16:13:36  <caitp>it doesn't really, does it
16:14:08  <caitp>anyway, I'm making myself dizzy thinking about it when I'm trying to be productive at other things.
16:15:11  <devsnek>btw how come exposing GC is bad, if anyone feels like explaining
16:23:01  <ljharb>devsnek: it exposes timing attacks and things like that, i think - also it could make web code depend on certain gc semantics which would force everyone to match them
16:24:00  <IgnoredAmbience>I recall some sandbox escape vulnerabilities have used garbage collection as part of the exploit. [citation needed]
16:24:36  <devsnek>so it could be done without directly observing gc?
16:25:13  <ljharb>devsnek: if you can know when it happens, you can infer a lot about the implementation, i believe
16:26:46  <IgnoredAmbience>Here's one case where GC was forced to trigger a use-after-free (from a skim read) https://googleprojectzero.blogspot.co.uk/2014/07/pwn4fun-spring-2014-safari-part-i_24.html
19:31:25  * keith_millerjoined
20:01:23  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:18:05  * keith_millerjoined
21:16:22  * not-an-aardvarkjoined
21:19:01  * srl295joined
21:31:00  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:32:11  * keith_millerjoined
22:31:55  * linclark_joined
22:41:47  * isHavvyjoined
22:42:40  * Havvyquit (Read error: Connection reset by peer)
22:49:47  * araiquit (Ping timeout: 276 seconds)
22:49:55  <zkat>how overly ambitious is it to put up 3 different proposals for stage 1? 👼
22:51:47  <zkat>I figure the bar for stage 1's pretty low, and if they're all fairly straightforward, I can just put them up and see what happens? :)
22:53:33  <cloudshu>depends on ambition of the proposal itself?
22:53:50  <cloudshu>3 60-minute timeboxes back-to-back would be very ambitious :)
22:54:40  <zkat>yeah
22:54:55  <zkat>not that big. The reason they're broken up is so they're more bite-sized ;)
22:55:15  <zkat>I got 1 15-min one, and one 60-min one that probably doesn't need that much anymore, plus a 30-minute one I'm thinking of tossing in.
22:55:39  <cloudshu>sounds good to me
22:55:50  <cloudshu>a lot of 30-minute items this time
22:56:22  <ljharb>seems totally fine
22:56:31  <cloudshu>this schedule looks pretty packed huh
22:57:20  <cloudshu>are we gonna try to prioritize higher staged proposals this time?
22:57:24  <ljharb>i was just going to make a TCO joke but i didn't have the heart
22:57:25  <cloudshu>i remember that being mentioned
22:57:32  <ljharb>cloudshu: we're going to discuss doing that next time
22:57:54  <cloudshu>ok
22:58:51  <ljharb>* i mean, we're going to discuss (in may) doing it next time (in july, +)
22:59:05  <cloudshu>that's how i interpreted you, yes
22:59:54  <rkirsling>whoa, pattern matching syntax was hugely revised, eh
23:01:38  <zkat>yeah
23:02:31  <zkat>I decided I really don't want to stick my hand in do{}'s pie until it's answered some of the same questions `match` would need to in order to be a nice expression that fits well into the language.
23:03:14  <zkat>and treating case legs as ConciseBody just made some small-but-impactful details not work right at all.
23:03:21  * jwaldenjoined
23:04:50  <zkat>I'm jumping on the "please expression all my statements" bandwagon. If `do{}` falls through, I'd _definitely_ at least like a standalone proposal for expression forms of all the if/try/for/while/switch statements.
23:05:15  <zkat>I'd rather pattern matching not invent its own snowflakey solution without everything else being considered at the same time.
23:05:53  <rkirsling>sounds wise :) looks like there are a lot of intertwining proposals in play
23:06:09  <rkirsling>exciting as an FP-inclined individual myself
23:06:28  <rkirsling>lots to read, lots to read...
23:07:53  <zkat>\o/
23:19:48  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
23:48:44  * keith_millerquit (Ping timeout: 260 seconds)
23:49:59  <bradleymeck>zkat: feel free to get Stage 1s out there, it lets other people see that it is being worked on
23:54:26  <Domenic>So uh I feel bad asking but are we getting pattern matching in catch() guards? Cuz that's really where I want it...
23:55:55  <ljharb>i think that's one of the "future proposals" kat has in the pattern matching repo
23:56:13  <TabAtkins>Yeah, `match` *creates* the pattern matching syntax, then other stuff can absorb that.
23:56:21  <ljharb>but to make it truly elegant you'd also want do expressions - otherwise you'
23:56:32  <ljharb>* you'd have to have something weird in the catch guard, probably
23:56:32  * keith_millerjoined
23:56:48  <ljharb>but once match {} and do {} land, then catch guards seem relatively simple
23:57:34  <bradleymeck>idk, if you have multiple types of errors you are guarding you definitely want it in the block which a statement works for
23:57:56  <Domenic>Ah found it OK https://github.com/tc39/proposal-pattern-matching/blob/latest/TO_INFINITY_AND_BEYOND.md#catch-match
23:58:40  <rkirsling>cool. 'cause yeah, Dart's `try {} on MySpecificException catch (e) {} catch (e) { /* default */ }` sure is nice
23:58:59  <Domenic>(Confused as to why all headings have greater-than signs before them...)
23:59:55  <TabAtkins>Huh, it looks like it might be a search-and-replace error. zkat?