C++ language support

[cpetig]

I have been working on a C++ bindings generator in a fork at https://github.com/cpetig/wit-bindgen for some time.

After a rewrite the code is less clumsy and could be considered for merging upstream once tests pass for more data types.

Please note that this generator is intended for host bindings (WAMR) as well and prefers most modern C++ wherever helpful. You can take a look at the intended API in https://github.com/cpetig/wit-bindgen/blob/main/crates/cpp/DESIGN.md .

[alexcrichton]

I think this'd be awesome to merge, thanks for working on this! I'd be happy to help review this when you feel it's ready.

[trcrsired]

better not. the problem is that these features are not freestanding C++ features. You will end up with troubles like binary bloat etc. C++ does not guarantee features that are not freestanding would exist. Plus EH is not well supported on wasm vms.

https://en.cppreference.com/w/cpp/freestanding

[cpetig]

better not. the problem is that these features are not freestanding C++ features. You will end up with troubles like binary bloat etc. C++ does not guarantee features that are not freestanding would exist. Plus EH is not well supported on wasm vms.

https://en.cppreference.com/w/cpp/freestanding

I need to guess what exactly you are recommending against.

One assumption could be to avoid using expected because the implementations are immature (and an embedded suitable (this is what I understand freestanding to imply) variant might take years to come).

Personally I am less affected because my primary target, AUTOSAR adaptive platform, brings its own Result class. Another option is to use a freely available implementation compatible with c++-17 (I think with MISRA targeting this older versions should soon phase out) https://github.com/TartanLlama/expected

PS: You can read about our plans to leverage WIT for adaptive platform in https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_ARARustApplications.pdf §7.2.1

[trcrsired]

better not. the problem is that these features are not freestanding C++ features. You will end up with troubles like binary bloat etc. C++ does not guarantee features that are not freestanding would exist. Plus EH is not well supported on wasm vms.
https://en.cppreference.com/w/cpp/freestanding

I need to guess what exactly you are recommending against.

One assumption could be to avoid using expected because the implementations are immature (and an embedded suitable (this is what I understand freestanding to imply) variant might take years to come).

Personally I am less affected because my primary target, AUTOSAR adaptive platform, brings its own Result class. Another option is to use a freely available implementation compatible with c++-17 (I think with MISRA targeting this older versions should soon phase out) https://github.com/TartanLlama/expected

PS: You can read about our plans to leverage WIT for adaptive platform in https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_ARARustApplications.pdf §7.2.1

expected does not make sense and i do not use it. The only solution is Herb Sutter's P0709.

[tschneidereit]

@trcrsired please refrain from this kind of unproductive and hostile comment. As all Bytecode Alliance projects, wit-bindgen is governed by our Code of Conduct, which we require all contributions (including comments on issues and PRs) to abide by.

Your comment violates the standards described in the Code of Conduct, so I'll hide it. If you want to discuss the merits of specific coding style or architecture decisions, you're free to do so, as long as you keep to respectful language, and accept that the maintainers of this project might not agree with your point of view and make decisions you disagree with.

[squillace]

"insanely inappropriate" is absolutely a point of view, and one that uses strong language implying an inability to think to pile emotion on top of its judgment. These are not a collaborative comments, regardless of your belief of its correctness. You are free to make your technical argument, of course! But a rhetorical attempt to characterize others' abilities to think "rationally" is not a technical argument.

[squillace]

You have complete freedom to disagree with the wasm standard, which of course you know so your comment is merely trolling. The joy of the world is this disagreement, and you remain absolutely free to spread your joy all over the internet. But here, you can make a technical argument. You made two: that because the PR isn't freestanding "there will be problems" and that in addition EH is not well supported on wasm vms.

We can evaluate those; but we won't be doing that with abuse.

[tschneidereit]

While I know that @squillace will wear the SJW label as a badge of honor, using it as a derogatory term is a very clear violation of our standards and code of conduct. @trcrsired, I will hide your comments and will ask you once more to engage productively.

[tschneidereit]

@cpetig as Alex says, this is great! Are there things still blocking it, or do you think it's ready to review? If so, can you open a PR?

[cpetig]

@tschneidereit Thank you for your interest here, I would like to finish support for (string|list|record|option|result)⨉(guest import|export)⨉(argument|result) before filing a PR. But if you already want to take a look at the code and monitor progress, I can easily create a draft one and add these as open tasks.

PS: The last days I have been busy merging components as a plugin architecture for https://veloren.net , so don't be alarmed by the slowed progress on this branch.

[tschneidereit]

I would like to finish support for (string|list|record|option|result)⨉(guest import|export)⨉(argument|result) before filing a PR.

That makes sense, yeah. And I'm not in a rush—I have a use case that currently works with the C generator, but which I'd love to port to C++, whenever that starts making sense.

PS: The last days I have been busy merging components as a plugin architecture for veloren.net , so don't be alarmed by the slowed progress on this branch.

Very cool! <3