Should it be possible to write a program that, given a Rust program, spits out a C11 program that does the same thing? Is it possible today?
This question affects many language points such as the memory model and how volatile reads and writes work. In particular, AFAICT, one cannot implement LLVM’s volatile reads and writes in ISO C11, because LLVM’s volatile read and write primitives cannot be expressed in C.
My own opinion is that it would be a useful experiment to build such a translator because it would be the easiest path towards an alternate Rust implementation not based on LLVM. This, in turn, would lead us to define Rust’s semantics in a more meaningful way than “whatever LLVM does” or “whatever rustc does.”
I also think that Rust should avoid needlessly diverging from C’s semantics. That is, Rust should prefer to avoid making design decisions that make translating Rust to C11 impossible. Otherwise, mixed Rust/C programs cannot be formally reasoned about, which is problematic in some cases since all Rust programs are a mix of Rust and C.
To be clear, I don’t think that Rust should be forced to do whatever C does. If there are things that Rust does that are clearly better and can’t be expressed in C, I’d rather Rust do the better thing than do the C-compatible thing. I would love to see a list of such things, if there are already such features.
Again, I bring this up because I saw a proposal that Rust’s semantics for volatile reads and writes be defined to be whatever LLVM does, which cannot be expressed (AFAICT) in C. I’ve also seen the discussion on the memory model where some people are proposing that Rust guaranteeing things that would be very expensive (AFAICT) to guarantee in a Rust program translated to C.
Note I’ve been kicking around the idea of writing a Rust-to-C translator so that I can use formal methods tools that have been (or are being) written for C to analyze Rust programs.