2021-10-11 [10:18:27.0157] i was thinking of getting a monthly working session call started on structs. i'll put a tentative calendar invite out, we can hash out times when asumu is back [10:48:33.0488] Sounds good to me. [10:51:00.0586] I'm hoping to finish up an update for resource-management for the next meeting, as I'm hoping a RAII-style `using const ...` declaration will be useful for locking for a future concurrent JS. I'd ask for stage 3, but my spec reviewers haven't had a chance to review the updated spec text. [10:52:22.0558] While not as terse as `using value expr` was, I switched the bindingless form to `using const void = expr` because it made both the syntax and the algorithms much simpler. [10:52:46.0449] (probable bikeshed at plenary to follow) 2021-10-18 [12:31:33.0702] hi folks, i'd like to nail down a time for the first working session meeting this Thurs, Oct 21 [12:31:42.0967] i've heard some conflicts for the current proposed time of 10-11AM PT [12:32:02.0953] asumu: does the current time work for you? [12:38:08.0778] shu: 10AM PT is fine with me, I could also potentially do other times (though I'm booked ~7-9AM PT) [13:05:31.0167] 10am on Oct 21 would work for me as well [13:25:29.0151] okay, let's stick with the current time then [13:25:40.0195] prioritizing what works for the champion group [13:25:44.0713] see you all then! 2021-10-19 [11:33:35.0878] shu: was an invite sent out or will this be on the TC39 events calendar? [13:32:21.0328] rbuckton: i sent an invite out [13:32:37.0045] i sent it to your work email [13:32:48.0118] rbuckton: ^ [14:09:14.0843] I can't seem to find it. [15:05:59.0308] rbuckton: i removed you and added you again, lmk if you see it [15:19:05.0997] I do see it now yes, thanks! 2021-10-20 [21:50:26.0747] I’d like an invite too, if that’s okay. [10:33:45.0919] jschoi: DM me your email you'd like the invite sent to 2021-10-21 [10:02:24.0174] /me is in the "asking to join" queue for the google meet 2021-10-25 [05:08:57.0033] Arf I missed this conversation. Please include me in the following events. Adding to the TC39 calendar would be nice 2021-10-28 [10:09:13.0914] there's been two issues raising the point that they find the motivation for non-shared structs not super compelling [10:09:48.0176] i can see where they're coming from, though i think the existence of wasmgc on non-shared memory alone is enough motivation for me [10:09:59.0996] would be interested in others' thoughts, especially rbuckton and asumu 2021-10-29 [20:12:28.0710] I'm personally more interested in the value we can get out of shared structs, and worry that having both might be more problematic in the long term. If we have to make design decisions later that effect things like shared functions, we could run into incompatibilities between shared and non-shared structs. [20:15:48.0238] That might mean that, until we can figure out shared code, structs might be data only (i.e., no associated behavior via methods/accessors on the prototype). I think I could live with that, assuming we continue to work towards a solution for shared code and concurrent JS. [06:01:49.0590] yes, i am like 95% interested in shared structs, but the wasmgc story, well, needs a story [06:02:00.0503] sounds like a good discussion topic for the next call [12:31:28.0087] What will WasmGC need that won't be provided by shared structs? [12:33:24.0411] shared structs have restrictions that non-shared wasmgc instances don't [12:33:38.0032] like being able to only point to other shared structs and primitives [12:37:14.0403] Are there other things we could do to shared structs to make it serve those needs? One thought I had while sketching out a concept for shared functions was thread-local storage, which could be used to store non-primitives with thread safety. There's also boxing, though that seemed contentious in the last plenary. [12:38:15.0923] * Are there other things we could do to shared structs to make it serve those needs? One thought I had while sketching out a concept for shared functions was thread-local storage, which could be used to store non-primitives with thread safety. There's also boxing, though that seemed contentious in the last plenary. [13:15:35.0866] i think if it is still an agreed goal that structs serve as JS reflections of wasmgc instances, i think it's unavoidable to have both shared and non-shared instances [13:15:45.0096] since multithreading for wasm is also opt-in [13:16:22.0830] i don't see how you can have shared structs serve the need of representing a non-shared wasmgc instance, or why that would be desirable [13:17:28.0533] TLS seems the opposite of sharing, i'm not sure how that relates to putting non-primitives into shared structs [13:18:16.0189] are you envisioning some kind of TLS box? i'd see that strictly as a follow on [13:18:31.0490] and that certainly wouldn't help the wasmgc use case [13:21:25.0396] i'd like to better understand why having both shared and non-shared structs is problematic in the long term [13:25:07.0278] one direction i could see this going is to restrict non-shared structs further, such that the _only_ additional restriction shared structs have is that you cannot assign non-shared struct objects into their fields [13:25:15.0928] that is, non-shared structs also become data-only, prototype-less things [13:26:35.0808] until such time we know how to relax both [13:27:46.0550] or more speculatively, with the `::` operator, perhaps the way to use structs OO-style is with `::` [13:28:12.0324] that's pretty palatable to me [13:57:02.0926] > <@shuyuguo:matrix.org> are you envisioning some kind of TLS box? i'd see that strictly as a follow on I was thinking about it as a follow-on, but was just throwing it out as an idea. [13:58:18.0765] Honestly, as much as I want methods and prototypes on structs, I do feel we need to solve concurrency before we add them. Otherwise we might paint ourselves into a corner with inconsistencies between non-shared structs and shared structs. [16:25:43.0878] Only using `::` for structs kind of goes against my long term vision for them, but it might be a viable option for the short term assuming `::` is adopted. There was a fair amount of pushback in the last plenary given the various proposals related to `this`. [16:33:55.0387] Yeah I definitely agree with "i don't see how you can have shared structs serve the need of representing a non-shared wasmgc instance" and commented along these lines on the GH issue. I don't think Wasm implementers will want to implement a JS API design that only uses shared structs at this point if it's hard to make it perfomant.