Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM.
Your argument was
interoperability and portability
1) Rust outputs to the same object file format as C, and can be natively linked against C/C++ code. So interoperability is no issue.
2) You have no portability gain as you have 3 choices x86, x64, and ARM. All of which Rust already supports.
Who needs more than one dialect of C or C++? I don't. Any systems I'm interested in may not support clang, but they have C11 compilers and C++14 compilers.
Rust is not interoperable with C++ as far as I know, and even if it was, I'm not interested in Rust for this discussion for reasons I've mentioned elsewhere.
The LLVM C backend was removed. Julia devs have a version that supports the LLVM bit code that they require, but I believe it is not everything LLVM can produce.
I was under the impression that march=cpp output C++ code that rebuilt the IR, not implemented the source program.
Thanks for the advice, although none of it really applies to what I'm suggesting.
Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM.
Your argument was
1) Rust outputs to the same object file format as C, and can be natively linked against C/C++ code. So interoperability is no issue.2) You have no portability gain as you have 3 choices x86, x64, and ARM. All of which Rust already supports.
Also your main request
or if you want C++