5 ms·
Could such a workaround come to the Rust language in the future. Maybe other programs will need a "safe" way to implement something similar that is currently im
by mtgx 7y ago
Could such a workaround come to the Rust language in the future. Maybe other programs will need a "safe" way to implement something similar that is currently impossible with the safe methods offered by Rust.
- unrealhoang 7y agoBut why? That’s is exactly the reason why unsafe exists: to open an escape hatch to do something that is impossible to do in safe Rust (and then wrap that under a safe interface). Your safe Rust, standard library, is constructed exactly the same way: based on unsafe. Unsafe doesn’t magically make your code unsafe, it’s just that you tell the compiler to trust you to handle the problem correctly (usually by meddling directly with pointers).
- Thaxll 7y agoFor me the question was more, isn't Rust supposed to have fearless concurrency meaning no "unsafe" part to modify data between threads.
- mmastrac 7y agoWhat would most likely here would be abstracting this problem into a library that could isolate "unsafe" in a place where it could be specified, tested and examined in isolation.
- TD-Linux 7y agoYou could add this to the standard library in the future. There is already the 1d version of this (slices). But you don't need to - it would be perfectly fine to live on its own.