Ok, thanks, finally found the source of transpose. That uses unsafe. Which of course means, all guarantees of safety are off. I am not sure why the usage of unsafe is necessary here, but one way or the other, safety now is in the hand of the programmer.
My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.
Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.
I think this is exactly the life lie of Rust. It claims to be memory safe and equally suited for system programming. But you get memory safety only when completely avoiding unsafe and it competes with C only when using unsafe. And it is certainly not true that you get memory safety in the part not using unsafe or that you only need to review the unsafe part. The memory safety of the safe part depends on the programmer maintaining invariances in the unsafe part that the Rust compilers needs to ensure the memory safety. At the same time the safety prerequisites of the unsafe parts can be violated by logic errors in the safe part (as in the transpose examples). It still helps to isolate the unsafe part, but in practice I am not convinced that the typical Rust code I see for system programming is fundamentally more secure than equally well designed C code which was also written with an eye towards memory safety and with use of modern tools to find problems.
My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.
Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.