diff --git a/main/2026/CG-2026-03-24.md b/main/2026/CG-2026-03-24.md index 7a0c6757..f5f48b36 100644 --- a/main/2026/CG-2026-03-24.md +++ b/main/2026/CG-2026-03-24.md @@ -19,13 +19,134 @@ No registration is required for VC meetings. The meeting is open to CG members o ## Agenda items for future meetings 1. Move JS-API Type Reflection back to Phase 2 or Phase 1 (https://github.com/WebAssembly/js-types/issues/55). Ryan Hunt, 15 minutes. +PDF download for archival ## Meeting Notes -To be filled in after the meeting. - ### Attendees + - Thomas Lively + - Derek Schuff + - Robin Freyler + - Manos Koukoutos + - Nick Fitzgerald + - Deepti Gandluri + - Heejin Ahn + - Francis McCabe + - Michael Ficarra + - Conrad Watt + - Chris Woods + - Erk Rose + - Chris Fallin + - Adam Bratschi-Kaye + - Yuri Iozzelli + - Sam Clegg + - Ryan Hunt + - Yury Delendik + - Paolo Severini + - Daniel Lehmann + - Steven Fontanella + - Rezvan Mahdavi Hezaveh + - Julien Pages + - Ryan Diaz + - Andreas Rossberg + - Emanuel Ziegler + - Ben Visness + - Matthias Liedtke + - Stephen Berard + - Jakob Kummerow + - Luke Wagner + - Brendan Dahl + - Guy Bedford + ### Proposals and discussions +#### 1. Move JS-API Type Reflection back to Phase 2 or Phase 1 (https://github.com/WebAssembly/js-types/issues/55). Ryan Hunt, 15 minutes. + + +RH Presenting slides. It would especially be good to find a champion + +DG: We couldn't move it forward because we didn't know what people were going to use it for. If there are reasons to prioritize this, that would be good to know. It used to be a blocker for JSPI, but that dependency was removed. +One thing that should go in is better documentation on the motivation. + +TL: In Binaryen we’ve been working on making the fuzzer more flexible for having arbitrary imports and exports. It would be great to be able to reflect on the imports and exports so the fuzzer can know what to expect. If we had this API in V8 we would definitely use it. As it is we would have to parse the module bytes but we’re not doing that because it was a pain. So this would be nice to have, even if not a blocker. + +SC (chat): Emscripten would really love to have `new WebAssembly.Function` for allowing JS functions to be added to the table. + +AR: I’ve seen people needing to synthesize a whole module just to work around the lack of new WebAssembly.Function, that shouldn’t be necessary. We also have this problem already in the existing API, e.g. you can't create globals and tables with the new types. We could focus on fixing that problem without adding fundamentally new functionality if we wanted to reduce the scope. The problem we ran into last time wasn’t so much of a problem was what to do with the new types, throwing, what the subtype should be on the API in the presence of types you can’t express, etc. But it makes sense to push back to phase 1 or 2 as long as we don't have a champion. + +DG: this is less about the gaps themselves, but webassembly.function was independently useful, but should we pull it out of the proposal? It's not great to cut things up too much, but maybe it makes sense here. + +AR: I agree except that WA.Function at least as a constructor isn’t so useful if you can’t express wasm types. It might still make sense to have WA.Function as a class, so we have a more refined way to express exported functions on the outside, but without it being a constructor. not sure how useful that would be. + +RH: I agree WA.Function is independently useful. There's a difference between gaps where the JS API is producing a value and places where it is consuming a value. Could start with a way to parse a type in a constructor that can be extended to support more types over time. Whereas a .type property returning something would be more fixed in shape. + +AR: That's a good point, we could have the Function constructor with the functionality that the global and table constructors have, with the wasm 1.0 types as arguments. But functions are more than just 2 list of value types because of recursion groups, etc. this would be a hack that’s not really forward compatible, but it might still be useful. Long term we need a more general representation than 2 lists of types. + +RH: If we had a WA.FunctionType and a mirror for all the types, you could imagine the legacy constructor would be redefinable in terms of those. + +BV (chat): This sounds like phase 1 discussion to me :) + +AR: as a bit of background, it was basically just an attempt to just turn the type syntax, model it directly in terms of arrays in JS, but not have it go through classes, but make it just simple like JSON. in principle this could still work with the richer type system but it would need more design work. + +TL: One thing we do when extending the core type system, is insert new syntactic instructions in the middle of the tree, e.g. a ref type refers to a heap type, and then custom desc comes along and you put a desc type node in that chain. If we did have an API that mirrored the new more complex syntax of the types, then when we add new syntax, we’d want to add new things to that API. if youre just adding properties to existent classes maybe thats compatible enough, but if you add whole new classes and change the types that properties return, that seems challenging. We might end up with this drift over time. Ben wrote in chat that this pounds like a phase 1 discussion and I agree. + + +AR: This is why I didn’t want to introduce classes as an abstraction, you can just add new fields to a record without changing meta structures, etc. hard to say whether that will really work, but that was the idea. + +BV: It seems like we’ve taken advantage of the ability to semantically reinterpret things in the spec. But once the internals are exposed to JS it becomes much harder to that, even in a dynamic language like JS, it sort of freezes the structure. We should talk about how much we want to freeze like that. We have "anyfunc" there and we can’t change that. + +RH: I think that whole conversation is a good motivation to go back a phase. Does anyone have a strong preference for phase 2? Otherwise I would say probably it should be phase 1. + +BD: If we go back, would we actually change the current proposal? It seems pretty complete for linear memory, this seems like feature creep to be adding things to the scope. It would be really nice to have WA.Function + +AR: even with linear memory we have things like custom page sizes, shared memory etc changing what the interface could look like. It’s not hard, but it’s still work. + +RH: I’d be supportive of splitting WA.Function out with constructors like what we have for globals and tables. It would be great for it to align with the type reflection feature, but I don't think it has to. +Design questions I’d want to see would be how to model type recursion and how much of the type syntax we are exposing. I could imagine one alternative to exposing the whole structure would be maybe having an opaque type that has query properties and type builder interface, that might give us more freedom. But that’s a reason I think it could benefit from redesign. + +BV (chat): Maybe we should just make a shared JS library for parsing a module preamble and reporting all the types...if it was a user library we could just change it in sync with the spec + +AR: It would still require a champion. + +TL: is anyone interested in picking up this, or any pieces of it? + +BD: it’s pretty far along, with 2 implementations? + +DG: V8 has one, I think that webkit might also have an incomplete one. + +RH: firefox has a roughly complete implementation for the 1.0 types. Not clear about the more advanced cases. I don’t think the implementation is the challenging part, it’s the spec and design. Exposing JS objects is easy. For the champion, the biggest work would be the spec and design. + +JK (chat): FWIW, we hate our implementation and would love to rip it out :) +It's causing no end of trouble because it's a special case that gets in the way all the time. + +TL: sounds like there’s some appetite for, rather than putting the whole thing back, carve out some piece that could stay at phase 3, and put the rest back at phase 1? Not sure how much sense that makes and how easy to pull apart. Maybe we should look into that before rewinding the whole thing? + +BV: doing that instead of rewinding the whole thing and then fast-tracking the existing parts forwarding again? + +TL: it does get us back to “we need a champion” again, but that sounds fine too. + +RH: it sounds like sending the whole thing back to phase 1, calling for a champion, and notinug that we’d be in favor of fast tracking the existing parts of WA.Function, we probably wouldn’t change our implementation. + +The alternative is that we do nothing and that it just sits at phase 3? + +RH: we get pinged about it sometimes, why aren’t we shipping it, etc + +DG: we might rip parts out, and if we made different design decision it might and up looking different. +It does get awkward having this at phase 3 without a realistic path to shipping it. + +TL: I just noticed ben’s post in the chat about a shared JS library. I’d be in favor of that too. + +AR(chat): a library would only work on source modules, though, not instances or individual objects + +TL: 5-way consensus poll to move the whole proposal back to phase 1. + +SF: 7 +F: 21 +N: 5 +A: 0 +SA: 0 + +That’s consensus, thanks everyone. + ### Closure