4 ms·

Thanks for pointing it out! It was also pointed out in my submission to the rustc book[1][2], and it has been updated since then, but it seems Cloudflare is sti

Thanks for pointing it out! It was also pointed out in my submission to the rustc book[1][2], and it has been updated since then, but it seems Cloudflare is still serving an outdated version sometimes. [1] https://github.com/rust-lang/rust/pull/76858#pullrequestreview-491983784 https://github.com/rust-lang/rust/pull/76858#pullrequestrevi... [2] https://github.com/rust-lang/rust/pull/76858/commits/344d8358014d85d0dd7fd5aefa3549ec615f72a6 https://github.com/rust-lang/rust/pull/76858/commits/344d835...

svrb 6y ago
Frankly the new version is still wrong. There's no such thing in rust as a "type not subject to the borrowing rules". Raw pointers don't respect borrowing, but they themselves are still subject to all the same borrowing rules and their pointees are subject to the same borrowing rules if aliased by a reference. In short, any claim whatsoever that it's possible to "turn off" borrowck is FUD. You might as well claim that Cell, RefCell, and Mutex turn off borrowck in safe rust (since they allow a kind of aliasing outside the borrowing discipline, just like pointers) when we know that's patently false.
- pornel 6y ago
  "FUD" is a strong accusation. I'd say it's just unclear language, and a subtle topic that's easy to misunderstand. I'm not suggesting malice here, because the deeper you go into the details, the more it's just language-lawyering. Rust has a memory model (AKA stacked borrows) that needs to be upheld, even by unsafe code and raw pointers. The difference is that for borrows, the borrow checker ensures this, and for raw pointers the programmer ensures this. So in a way raw pointers do bypass the borrow checker and the conservative borrow checker rules. Then there's the magical UnsafeCell type that is an opt-out of the usual thread-safe memory access rules, and allows doing things that would be Undefined Behavior otherwise. This type is at the heart of types like Mutex and atomics.
  - svrb 6y ago
    > and a subtle topic that's easy to misunderstand You're right, yet there's a higher level of responsibility for people who are claiming to be able to teach others about these things (which grandparent comment does) to understand and to use language which doesn't tend to mislead.
    - rcvalle 6y ago
      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

Frankly the new version is still wrong. There's no such thing in rust as a "type not subject to the borrowing rules". Raw pointers don't respect borrowing, but they themselves are still subject to all the same borrowing rules and their pointees are subject to the same borrowing rules if aliased by a reference. In short, any claim whatsoever that it's possible to "turn off" borrowck is FUD. You might as well claim that Cell, RefCell, and Mutex turn off borrowck in safe rust (since they allow a kind of aliasing outside the borrowing discipline, just like pointers) when we know that's patently false.

pornel 6y ago
"FUD" is a strong accusation. I'd say it's just unclear language, and a subtle topic that's easy to misunderstand. I'm not suggesting malice here, because the deeper you go into the details, the more it's just language-lawyering. Rust has a memory model (AKA stacked borrows) that needs to be upheld, even by unsafe code and raw pointers. The difference is that for borrows, the borrow checker ensures this, and for raw pointers the programmer ensures this. So in a way raw pointers do bypass the borrow checker and the conservative borrow checker rules. Then there's the magical UnsafeCell type that is an opt-out of the usual thread-safe memory access rules, and allows doing things that would be Undefined Behavior otherwise. This type is at the heart of types like Mutex and atomics.
- svrb 6y ago
  > and a subtle topic that's easy to misunderstand You're right, yet there's a higher level of responsibility for people who are claiming to be able to teach others about these things (which grandparent comment does) to understand and to use language which doesn't tend to mislead.
  - rcvalle 6y ago
    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...