I think that keeping an exact one-to-one mapping makes this tool a lot more useful. There's no telling what code depends on C idioms that would be broken by using a Rust idiom instead. Generating 100% equivalent code means that programmers can make intelligent decisions about when to switch over to Rust idioms as they continue developing the program.

Yeah, once you've got equivalent Rust, the rest is just optimization that should probably be implemented in the Rust compiler. No reason to put that stuff in the niche transpiler.

> Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite design goals

Yes the author has explicitly noted that they want a compiler as syntax-directed as possible, semantics change would go against that grain. In that spirit, idiomatic alterations would be the domain of rust-land fixers and linters (e.g. `cargo wololo` or `cargo clippy | rustfix`)

So you could chain Corrode with one of those to get a C-to-idiomatic-Rust converter?

FWIW, I googled those; Clippy and rustfix just seemed to be linters that can't detect things like "you're not mutating this so drop `mut`", and I couldn't find wololo.

1. A special case could be added for `main`, but it's no big deal.

2. This seems difficult as the C arguments were mutable; the algorithm would have to start doing analysis rather than direct translation.

3. Quite difficult to "know" that this printf doesn't write to its arguments, especially since the printf is manually declared.

Regarding 1., If you're still reading, it looks like they discuss what they'd have to do to move `main` to its correct Rust type:

https://github.com/jameysharp/corrode/issues/20