| 03:12 | <rbuckton> | 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. |
| 03:15 | <rbuckton> | 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. |
| 13:01 | <shu> | yes, i am like 95% interested in shared structs, but the wasmgc story, well, needs a story |
| 13:02 | <shu> | sounds like a good discussion topic for the next call |
| 19:31 | <rbuckton> | What will WasmGC need that won't be provided by shared structs? |
| 19:33 | <shu> | shared structs have restrictions that non-shared wasmgc instances don't |
| 19:33 | <shu> | like being able to only point to other shared structs and primitives |
| 19:37 | <rbuckton> | 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. |
| 20:15 | <shu> | 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 |
| 20:15 | <shu> | since multithreading for wasm is also opt-in |
| 20:16 | <shu> | 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 |
| 20:17 | <shu> | TLS seems the opposite of sharing, i'm not sure how that relates to putting non-primitives into shared structs |
| 20:18 | <shu> | are you envisioning some kind of TLS box? i'd see that strictly as a follow on |
| 20:18 | <shu> | and that certainly wouldn't help the wasmgc use case |
| 20:21 | <shu> | i'd like to better understand why having both shared and non-shared structs is problematic in the long term |
| 20:25 | <shu> | 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 |
| 20:25 | <shu> | that is, non-shared structs also become data-only, prototype-less things |
| 20:26 | <shu> | until such time we know how to relax both |
| 20:27 | <shu> | or more speculatively, with the :: operator, perhaps the way to use structs OO-style is with :: |
| 20:28 | <shu> | that's pretty palatable to me |
| 20:57 | <rbuckton> | are you envisioning some kind of TLS box? i'd see that strictly as a follow on |
| 20:58 | <rbuckton> | 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. |
| 23:25 | <rbuckton> | 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. |
| 23:33 | <asumu> | 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. |