It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these four features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.
So how do I disable EVERY safety checks (I just want to try something out for my own learning experience I am not planning to use unsafe code on anything (unless if I really have to))?
You're approaching this from wrong perspective. It's like "how do I completely disable static typing in C". You can't, but there are plenty of ways to break it.
Similarly in Rust you can't disable some checks directly, but you can cast references to unchecked pointers, and from there you can ruin safety as much as you like
The existence of a forum is not an excuse to not read the documentation.
The answer can be found by opening the book, clicking "search", typing "cast" and clicking on the second result which specifically tells you how to cast references to pointers. It took me ten seconds to find that, including page loads. Typing "rust cast references to unchecked pointers" into Google also gives you the answer on the first link (to the first edition, but it's still correct).
Forums and the like exist to fill in gaps in the documentation, not to have other people do basic research for you.
The "safety checks" are not some opt-out extra functionality. Actually they're exactly the process that the compiler "read"s your code and start establishing assumptions about your code. You asked how to stop the compiler from establishing those assumptions but still generate valid executable programs, well... the only way is to stop using casual functionalities of the language and use the cutting-edge ones like raw pointers, etc instead. But, why bother?
That's a little harsh, @DanielKeep, when Google doesn't always give everybody the same answer to the same question ("results personalization"), and there's a decent chance they've never heard of The Book (especially with a cryptic way you refer to it).
Gotta say that I agree with @notriddle here. If you aren’t interested in helping someone who is asking a question that’s easily found, that’s okay. Just don’t reply to the thread. There are others who are, and they can take the time to answer. “RTFM” is not how we do things around here.
Somewhere about that, yeah. But as someone who learned to program from books (like, the real ones made of dead trees), seeing people unwilling to do even basic research themselves when they have access to some of the best search tools in all of human history is absolutely infuriating.
I had to make do with Altavista and card catalogues. Google giving inconsistent results (that are usually really good irrespective) is about a bazillion times better.
Even whilst Google might not give consistent results, the book's search should. That was kind of my point: if they'd just looked at the documentation, they'd have answered their own question in about the same time it took them to write the follow-up question, let alone wait for a response. Not looking in the book is literally wasting their own time.
And I really don't think it's at all unreasonable to expect people to go to the official website of a language, click the first link on the page (which is "Documentation") and then click the first non-header link on that page, which is to the book. It's the very first thing they should find.
Just to be clear: my contention is with the attitude of treating a forum (and the people volunteering to help) as a substitute for said basic research. I think that's profoundly disrespectful both to the people on the forum, and the people who spend so much time and energy making the docs as good as they are. Plus, like I said, it's a waste of their own time.
I don't actually have a problem with copying and pasting a link to the book into a discussion. Teach a newbie how to fish, don't just feed them. Besides, Steve and associates have done a better job with all the time and iteration than any off-the-cuff description any of us would write.
I do have a problem with assuming that someone already knows what you're talking about. "Read the book" is not enough information! Don't just say "the book", link to it! That's part of how Google judges the quality of a resource anyway.
True (and a good thing!), but "RTFM" was @Joe232's phrase, and I think that was an overreaction.
Moreover, @joe232, you seem to have a habit of starting forum threads to ask questions that aren't as meaningful as you think they are, and then insisting upon a "simple" answer. In this case, it's in no one's best interest to give you a copy-and-paste "recipe" for casting raw pointers, because your question indicates that you don't understand what Rust's safety guarantees are, and it's not clear how casting pointers will help you learn.
Obviously this "program in C" answer is a bit flippant, @joe232, but it's also the closest thing to a "simple" answer to your question. C is syntactically similar to Rust, and it permits (and, for anything non-trivial, requires) manual unsafe memory manipulation.
I agree that it would be nice to have another version of unsafe that could disable the borrow checker in a few select places. With a little extra verbosity, raw pointers however can do pretty much anything you want. Example of multiple mutable borrows:
fn main() {
let mut x = 1u64;
let y = unsafe { &mut *(&mut x as *mut u64) };
let z = unsafe { &mut *(&mut x as *mut u64) };
println!("{} {} {}", x, y, z);
*y = 2;
println!("{} {} {}", x, y, z);
*z = 3;
println!("{} {} {}", x, y, z);
}
