Christof Petig

> > ``` > > C++ guest support C++ language support #826 > > symmetric C++ API (I think the old one is horrible to understand, because move semantic for...

Update: I just got `future` and `stream` fully operational mixing native compiled C++ and Rust in a fully automated test case. Also the alien move semantic was a misunderstanding between...

P³S: Previously I tried avoiding all memory allocation by only returning borrowed objects and maintaining `cabi_post_`, but this makes ownership reasoning very difficult, see the bullet points in #175 ....

Ideally this could come with a future symmetric *API* option for C++ as well, but this is a choice internal to the bindings code and not related to the ABI.

The benefits of a symmetric ABI manifest in the shared everything case. For shared nothing the calling-into-a-component direction becomes more complex because the argument memory needs to be freed/reused by...

Separating symmetric ABI as an encoding convention for native compilation is a very interesting take on this. I can imagine wit-bindgen outputting target specific code supporting both ABIs with the...

I understand your sentiment about fused components, we either need separate binaries (shared objects) or tight control of the symbols across the resulting binary to avoid fusing separate global variables...

> If the goal of a symmetric native ABI is to have no adapters, I expect it will already require very different bindgen than what's currently emitted for wasm (since...

Please excuse the large amount of replies! The additional choice to use the same componentized source code as this highly efficient native solution, re-applying the canonical code generator and then...

> I worked on above mentioned prototype for nearly a year using the canonical ABI (and a host side connection fabric) and never completed it, but with symmetric ABI it...