Nothing stops you from leaking memory in Rust either, it is considered memory safe, see std::mem::forget. Rust only safes you from use-after-free and double-free.
Re:Announcing Rust 1.20
by staticassertion on Thursday August 31, 2017 @06:58PM
(#15144698)
And integer out of bounds, and (most) segfaults, and data races, etc
Re:Announcing Rust 1.20
by steveklabnik on Thursday August 31, 2017 @07:04PM
(#15144737)
Notably integer overflow is NOT UB and is checked in debug builds.
Re:Announcing Rust 1.20
by staticassertion on Thursday August 31, 2017 @07:35PM
(#15144924)
Sorry, I should have said array OOB.
Re:Announcing Rust 1.20
by steveklabnik on Thursday August 31, 2017 @07:44PM
(#15144977)
Yeah, it's all good!
It's still "hard to get right" in that at any time nothing is stopping you from violating any of the assumptions that make this "easy". It's never easy to write a solution that's "guaranteed to be safe" in C, but that's what you're trying to do by writing such a solution in Rust. To give but one example, nothing in C will stop your nodes from containing some resources which needs to be manually destructed and which get leaked when the stack frame is reclaimed.
Rust is going to require you to make those assumptions explicit, so that it can enforce them -- in this case, you need to explicitly restrict your solution to dealing with Copy types, which by construction don't implement Drop, and therefore have no destructors.
But at the end of the day, if all you want to do is swear to the compiler that you know what you're doing and you promise to not be stupid, wrap it in an unsafe and get C-style consequences if you got things wrong. You get C-Style easiness only by explicitly abandoning the attempt at guaranteeing safety for every type and scenario your solution could be used with.