| 04:00 | <Mathieu Hofman> | Mathieu Hofman: here's a hypothetical when you're back. would making shared structs inaccessible outside of |
| 04:07 | <Mathieu Hofman> | This is a pretty broad thing to be skeptical of. How does this fit together with rbuckton's feedback that methods were important for usability? Also, are you considering that the fundamental technology ("TLS") is needed for Wasm anyway, so most of the complexity will be there in the system either way? |
| 04:14 | <Mathieu Hofman> | even though FinalizationRegistry uses a similarly function/constructor-based API with no syntax, that doesn't really provide any meaningful friction to prevent abuse. The motivation for abuse doesn't come from convenient syntax but rather useful semantics that people misunderstand and want to get at. Shared structs is an improvement over SAB for complex value types. However SAB did force you to think about what you were doing when coming from an object model. The concern here is that an author can too easily take a regular non shared aware class, and transform it into a shared struct, without really thinking about what they're doing. |
| 11:58 | <littledan> | For wasm shared objects, one approach is for them to be opaque obects in JS, without any fields. Afaik, there is also no proposal for attaching prototypes to non-shared wasm refs either. So I fail to see how the complexity for this JS feature would already be there. |
| 12:58 | <rbuckton> | For wasm shared objects, one approach is for them to be opaque obects in JS, without any fields. Afaik, there is also no proposal for attaching prototypes to non-shared wasm refs either. So I fail to see how the complexity for this JS feature would already be there. WeakMap keys so that such proxies work. As a result, opaque WASM shared objects are not inherently safer, just slower due to indirection and FFI marshaling. When I brought up having WASM shared objects be opaque entities in a prior structs meeting, the main purpose was to discuss a worst case fallback position if we don't have a comprehensive story for JS shared objects. If WASM shared objects were to be introduced as ordinary JS objects and we were to want to later introduce JS shared structs with unique semantics around field reads and writes (such as what I discussed above re unsafe), then mutable WASM shared objects couldn't align with that approach without breaking existing consumers. Whether WASM shared objects are opaque or not has nothing to do with thread safety, only runtime semantic consistency. Thread safety is still a split responsibility between the shared object implementer and shared object consumer based on the needs of any given use case. |
| 14:08 | <shu> | For wasm shared objects, one approach is for them to be opaque obects in JS, without any fields. Afaik, there is also no proposal for attaching prototypes to non-shared wasm refs either. So I fail to see how the complexity for this JS feature would already be there. |
| 14:09 | <shu> | what do you mean by making inaccessible? I doubt you mean preventing interaction with instances of share structs outside these blocks? I don't see how could even work. |
| 14:09 | <shu> | i said hypothetical |
| 14:09 | <shu> | suspend your disbelief |
| 14:09 | <shu> | if it's possible, is that considered "enough friction" |
| 14:13 | <shu> | here's what i want to do: i'd like to get your side to articulate a greatest lower bound on what's "enough friction", then we analyze why that's considered enough. if there's a design principle there that's not "because we feel like it is", then happy to continue the discussion, otherwise not productive |
| 14:17 | <shu> | For wasm shared objects, one approach is for them to be opaque obects in JS, without any fields. Afaik, there is also no proposal for attaching prototypes to non-shared wasm refs either. So I fail to see how the complexity for this JS feature would already be there. |
| 14:28 | <rbuckton> | If you wanted, for example, to implement something akin to Rust's
|
| 17:14 | <littledan> | It's quite frustrating and feels counterproductive that, to pursue features like this, we have to resort to these frequent "threats" that it will come anyway. I wish we could focus on how the design should go, rather than whether it should be cancelled. |
| 17:16 | <littledan> | This style of discourse is a barrier to inclusion. E.g., for AsyncContext, it took years until people joined Chengzhong to talk through why it wasn't a fatally bad idea with respect to SES ideals. |
| 17:17 | <littledan> | Many us are spending work time on these projects, and this sort of opposition also makes it more difficult to justify spending time on these investments. |
| 17:18 | <littledan> | Of course we shouldn't add everything to JS, but somehow we need to be able to open the discussion, talk it through, and draw a conclusion, rather than rehashing the same concerns for years. |