4 ms·

I'm all open to suggestions on how it can be better worded to not cause any misunderstandings; let me know how I can improve it.

svrb 6y ago
Just delete that fragment "and new types ...". No part of it is true. Unsafe blocks do not introduce any new types anyways. You can do anything at all with a pointer, except dereference it, outside of an unsafe block. There's no such thing as an "unsafe type". Safe rust can do anything it wants to with an UnsafeCell, for example, except get inside it. If you really must, you can say "and allows dereferencing raw pointers", but that's something which is true of unsafe blocks, not "Unsafe Rust". Which, incidentally, is not a thing. If someone says "unsafe rust" what they mean is "the part of rust outside the safe subset"; but when you capitalize it and say it "introduces" all these things you make it sound like a separate language...
- rcvalle 6y ago
  Thanks for the suggestion, but I don't think removing it would be an improvement. The Rust Programming Language book (part of the language's official documentation)[1], which along the compiler source I used as reference literature for this post, does refer to Unsafe Rust as a "second language": > All the code we’ve discussed so far has had Rust’s memory safety guarantees enforced at compile time. However, Rust has a second language hidden inside it that doesn’t enforce these memory safety guarantees: it’s called unsafe Rust and works just like regular Rust. The choice of capitalizing unsafe is merely to make "unsafe" alongside "Rust" a (proper) noun (i.e., Unsafe Rust) instead of risking it being read as an adjective, which would be incorrect, and doesn't imply a second language by any means even though the official documentation refer to it as such. Even though raw pointers can be created in safe code, the official documentation refer to them as belonging to Unsafe Rust[2]: > In Chapter 4, in the “Dangling References” section, we mentioned that the compiler ensures references are always valid. Unsafe Rust has two new types called raw pointers that are similar to references. As with references, raw pointers can be immutable or mutable and are written as * const T and * mut T, respectively. The asterisk isn’t the dereference operator; it’s part of the type name. The "and new types that are not subject to the borrowing rules" was based on the previous (i.e. "Unsafe Rust has two new types called raw pointers") and the following, also from the official documentation[2]: > Different from references and smart pointers, raw pointers are allowed to ignore the borrowing rules by having both immutable and mutable pointers or multiple mutable pointers [point] to the same location. I honestly don't know how to make it much better than it is in the official documentation, but as I said before, I'm all open to suggestions on how it can be better worded to not cause any misunderstandings. Let me know if you have any other suggestions. [1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html [2] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#dereferencing-a-raw-pointer https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#dere...
  - svrb 6y ago
    So you're open to any suggestion except one which changes what you wrote? If the documentation claims that unsafe rust introduces new types, then it is wrong. It is demonstrably false. You can literally fire up a text editor and disprove this in about 15 seconds (if you're a slow typist). As someone holding themselves out to be a teacher you have a responsibility to fact-check like that, if not from the beginning, at least when informed that there's a mistake. Adding to the volume of incorrect documentation instead of fixing it can only come from a desire to be (rather to seem) right and be recognized rather from a sincere desire to actually teach and assist.
    - rcvalle 6y ago
      You're assuming that because you can create raw pointers in safe code, they were not introduced because or belong to Unsafe Rust, which is an incorrect assumption. If you still think that both my contribution and the official documentation are incorrect, you're welcome to start a discussion on my contribution's PR, and open an issue on the official documentation repository. As I said before, I'm all open to suggestions on how it can be better worded to not cause any misunderstandings, but these have to be constructive suggestions that would actually improve it.
      - svrb 6y ago
        Can you explain why you believe "remove the misleading sentence" is not constructive?

svrb 6y ago

Just delete that fragment "and new types ...". No part of it is true. Unsafe blocks do not introduce any new types anyways. You can do anything at all with a pointer, except dereference it, outside of an unsafe block. There's no such thing as an "unsafe type". Safe rust can do anything it wants to with an UnsafeCell, for example, except get inside it. If you really must, you can say "and allows dereferencing raw pointers", but that's something which is true of unsafe blocks, not "Unsafe Rust". Which, incidentally, is not a thing. If someone says "unsafe rust" what they mean is "the part of rust outside the safe subset"; but when you capitalize it and say it "introduces" all these things you make it sound like a separate language...

rcvalle 6y ago
Thanks for the suggestion, but I don't think removing it would be an improvement. The Rust Programming Language book (part of the language's official documentation)[1], which along the compiler source I used as reference literature for this post, does refer to Unsafe Rust as a "second language": > All the code we’ve discussed so far has had Rust’s memory safety guarantees enforced at compile time. However, Rust has a second language hidden inside it that doesn’t enforce these memory safety guarantees: it’s called unsafe Rust and works just like regular Rust. The choice of capitalizing unsafe is merely to make "unsafe" alongside "Rust" a (proper) noun (i.e., Unsafe Rust) instead of risking it being read as an adjective, which would be incorrect, and doesn't imply a second language by any means even though the official documentation refer to it as such. Even though raw pointers can be created in safe code, the official documentation refer to them as belonging to Unsafe Rust[2]: > In Chapter 4, in the “Dangling References” section, we mentioned that the compiler ensures references are always valid. Unsafe Rust has two new types called raw pointers that are similar to references. As with references, raw pointers can be immutable or mutable and are written as * const T and * mut T, respectively. The asterisk isn’t the dereference operator; it’s part of the type name. The "and new types that are not subject to the borrowing rules" was based on the previous (i.e. "Unsafe Rust has two new types called raw pointers") and the following, also from the official documentation[2]: > Different from references and smart pointers, raw pointers are allowed to ignore the borrowing rules by having both immutable and mutable pointers or multiple mutable pointers [point] to the same location. I honestly don't know how to make it much better than it is in the official documentation, but as I said before, I'm all open to suggestions on how it can be better worded to not cause any misunderstandings. Let me know if you have any other suggestions. [1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html [2] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#dereferencing-a-raw-pointer https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#dere...
- svrb 6y ago
  So you're open to any suggestion except one which changes what you wrote? If the documentation claims that unsafe rust introduces new types, then it is wrong. It is demonstrably false. You can literally fire up a text editor and disprove this in about 15 seconds (if you're a slow typist). As someone holding themselves out to be a teacher you have a responsibility to fact-check like that, if not from the beginning, at least when informed that there's a mistake. Adding to the volume of incorrect documentation instead of fixing it can only come from a desire to be (rather to seem) right and be recognized rather from a sincere desire to actually teach and assist.
  - rcvalle 6y ago
    You're assuming that because you can create raw pointers in safe code, they were not introduced because or belong to Unsafe Rust, which is an incorrect assumption. If you still think that both my contribution and the official documentation are incorrect, you're welcome to start a discussion on my contribution's PR, and open an issue on the official documentation repository. As I said before, I'm all open to suggestions on how it can be better worded to not cause any misunderstandings, but these have to be constructive suggestions that would actually improve it.
    - svrb 6y ago
      Can you explain why you believe "remove the misleading sentence" is not constructive?