Update CG-05-06.md

main/2025/CG-05-06.md

@@ -24,10 +24,90 @@ No registration is required for VC meetings. The meeting is open to CG members o
 
 ## Meeting Notes
 
-To be filled in after the meeting.
-
 ### Attendees
 
+- Thomas Lively
+- Derek Schuff
+- Robin Freyler
+- Nick Fitzgerald
+- Erik Rose
+- Ricky Vetter
+- Bailey Hayes
+- Paolo Severini
+- Shravan Narayan
+- Chris Fallin
+- Michael Ficarra
+- Andreas Rossberg
+- Adam Bratschi-Kaye
+- Yan Chen
+- Manos Koukoutos
+- Emanuel Ziegler
+- Johnnie Birch
+- Yury Delendik
+- Alex Crichton
+- Rahul Chaphalkar
+- David Degazio
+- Heejin Ahn
+- Jakob Kummerow
+- Paul Osborne
+- Sergey Rubanov
+- Oscar Spencer
+- Chris Woods
+- Zalim Bashorov
+- Colin Murphy
+- Nuno Pereira
+- Andrew Brown
+- Brendan Dahl
+- Sean Jensen-Grey
+- Sehyo Chang
+- Ben Visness
+- Yosh Wuyts
+- Keith Winstein
+- Julien Pages
+
 ### Proposals and discussions
 
+#### Announcement: [Registration](https://github.com/WebAssembly/meetings/blob/main/main/2025/CG-10.md#registration) open for October CG meeting in Munich 
+
+TL: CG meeting will be October 28 and 29, research day October 30 at the Google office in Munich, Germany. Registration is open. It's a long way away, but please submit PRs adding agenda items at any point.
+
+#### [Pre-proposal: More array constructors](https://github.com/WebAssembly/design/issues/1561), potential vote for phase 1 (Nick Fitzgerald, 20 minutes)
+
+NF presenting [slides](https://docs.google.com/presentation/d/13kVf0Ilctr1iy5CnUuwANafPN1vtrbhDS8tGGV6uiIc/edit#slide=id.p)
+
+JK (chat): is there a use case for `array.new_table` or is that just suggested "for completeness"?
+
+NF: I guess completeness. You can imagine you’d want to have it if you aren't using traditional memories; tables are like memories for references.
+
+BV (chat): Funny overlap there with array.new_elem, but I think it's probably reasonable. (Also, I have yet to see anyone actually use array.new_elem.)
+
+AR: Can you go back to the motivation? I think it’s totally fine to add these instructions, they are natural to have. But whether they really give you what it says here, I have some doubts. In particular I’m not sure the zero copy thing will work in practice. Languages will continue to use mutable representation internally, because they have so many ways to construct things that are immutable in the source language. They will probably still have to copy in e.g. the component model. Maybe even twice. 
+
+NF: I am prototyping GC support in the CM right now. My goal is to support where the wasm program chooses the representation they pass, so they can choose mutable or immutable, where mutable forces the copy and we’ll try to minimize it. If they can work with things in an immutable way we can avoid them. But yes, in the limit there will be a copy if they can’t make it immutable. And that’s ok, its trying to widen the use cases that can get it.
+
+AR: I’m fine with that, basically just wanted to express that I’m skeptical that this will be a common case. Most languages I don't think will be able to use immutable arrays. It doesn’t invalidate the proposal, but I think it will be more of a niche case. Similarly with the optimization opportunities, do we have numbers that back that up, that this makes a difference in practice?
+
+NF: I don't have numbers for the GC barrier stuff, but I know we got as large as a 10% improvement on some benchmarks when we added an alias analysis in Cranelift.
+
+AR: Again the same kind of thing applies, probably unless we actually add something like freeze, most languages won’t be able to use that in their runtime; for the same reason that optimization opportunity might not materialize in practice. It would be interesting to see. So mostly this is just so people won’t think this will make a huge performance difference. But it’s still nice because of expressivity. It was a little weird before with the asymmetry. 
+We could also think, why can’t you read from a data segment with instructions. But I don't want to go there right now. 
+
+An observation: the super-general instruction you talked about on your last slide- there is theory around this. An "unfold" operator. But usually this only works with closures and a lot of polymorphism. Probably won't fly in WebAssembly.
+
+BV: I think all of the expressivity reasons make sense to me. I think it would be good to move forward with this in general. One remark, I think the matrix we are building up of indexed collections of refs or bytes that can maybe/maybe not grow, is getting a little crazy. It would be interesting to think about how this could be simplified going forward. But it’s funny that arrays have some properties of memories and some of tables, and we are trying to plug these differences.
+
+AR: That's a good point. I expect that at some point we will have copy operators between memories and arrays and tables and arrays. I don't necessarily agree that it's weird. We always had both tables and memories.
+
+TL: have you thought about whether any of these instructions should be constant expressions?
+
+NF: no; off the cuff I would think that all of them could be. Maybe not new_array? I guess you could global.get another array and copy. So, why not?
+
+TL: any reason they shouldn’t be? AR?
+
+AR: not that I know of. new_elem isn't constant right now for section ordering reasons. That would be the main constraint there and then we are back to the question of should we relax section ordering.
+
+TL: no more questions. I think we can do a unanimous consensus vote for phase one as in the slide. If there are objections, please speak up now.
+
+No objections, Proposal moves to phase 1.
+
 ### Closure