Should Wren compile as C++ code?

[graphitemaster]

I make use of the amalgamated builds to vendor Wren into a C++ project which means compiling it as if it were regular C++ code. It's possible to keep it as C and do some stuff on my end but I'm mostly curious if this is a supported use case or should be. Full disclosure, I think it should be (if it isn't already) and I already vendor tons of existing single-file C libraries this way so I don't see why not.

If there is interest in this though, there are some minor issues that I've run into attempting to build Wren this way which are easy to work around and would make supporting this use case easier. The main one is the use of the module identifier which is now a C++20 keyword in one place. The other is how aggregates are initialized, specifically this one,

WrenLoadModuleResult result = {0};

Does not actually initialize all fields of result to 0 like it does in C. I propose just using memset(&result, 0, sizeof result); here otherwise some per-language stuff needs to be done there which sucks. In C++ simply having = {} would initialize all the fields to their default values but that doesn't have the same behavior in C.

[graphitemaster]

In a similar vein, the use of the register storage class specifier is deprecated in C++17 and being removed in future versions. I get warnings for it but it doesn't break the build. I wonder if maybe we could put that behind a WREN_REGISTER macro or something that defines out to nothing in the case of __cplusplus being present.

[mhermier]

Technically it should complile cleanly in C++98 there is no guarantee for future versions. Personally, I made some patch to remove inlining. After some test GCC and clang builds had virtually no regression.