> I've seen what comes out of the transpiler. Nobody should touch that code by hand. It's awful Rust, and uglier than the original C.
I can't disagree here. I think the original idea was to rely on automated refactoring tools to try to make the generated Rust somewhat more palatable, but I never was able to get that working.
> C23 doesn't actually use that info.
True; the intent is to require it so that it can be leveraged by future extensions. The C committee tends to move glacially.
The real problem is not translating code. It's translating data types. If you can determine that a "char *" in C can be a Vec in Rust, you're most of the way there. It's no longer ambiguous what to do with the accesses.
This is where I think LLMs could help. Ask an LLM "In this code, could variable "buf" be safely represented as a Rust "Vec", and if so, what is its length?. LLMs don't really know the languages, but they have access to many samples, which is probably good enough to get a correct guess most of the time. That's enough to provide annotation hints to a dumb translator. The problem here is translating C idioms to Rust idioms, which is an LLM kind of problem.
They have made some improvements here recently. There is a lot less unsafe generated. The rest is more idiomatic too. The cost is that it will be throwing panics everywhere until you fix the faulty assumptions it asserted. I like the new way better.
I can't disagree here. I think the original idea was to rely on automated refactoring tools to try to make the generated Rust somewhat more palatable, but I never was able to get that working.
> C23 doesn't actually use that info.
True; the intent is to require it so that it can be leveraged by future extensions. The C committee tends to move glacially.