5 ms·

Looking at the archive.org captures just before [1] and just after [2] the article was published, it looks like it was meant to be this line of code, now on lin

Looking at the archive.org captures just before [1] and just after [2] the article was published, it looks like it was meant to be this line of code, now on line 2779 [3]: let mid = left + size / 2; [1] https://web.archive.org/web/20230602210213/https://doc.rust-lang.org/src/core/slice/mod.rs.html https://web.archive.org/web/20230602210213/https://doc.rust-... [2] https://web.archive.org/web/20230709221353/https://doc.rust-lang.org/src/core/slice/mod.rs.html https://web.archive.org/web/20230709221353/https://doc.rust-... [3] https://doc.rust-lang.org/src/core/slice/mod.rs.html#2779 https://doc.rust-lang.org/src/core/slice/mod.rs.html#2779

LoganDark 3y ago
Alright, and as a versioned link that'll be: https://github.com/rust-lang/rust/blob/7d8386f05cedf33c7475cbb44f84178df5919202/library/core/src/slice/mod.rs#L2781 https://github.com/rust-lang/rust/blob/7d8386f05cedf33c7475c... Thank you!
- veber-alex 3y ago
  You can get versioned link directly into rustdoc: https://doc.rust-lang.org/1.71.1/src/core/slice/mod.rs.html#2779 https://doc.rust-lang.org/1.71.1/src/core/slice/mod.rs.html#...
  - LoganDark 3y ago
    I couldn't find any direct references to this anywhere, believe me I spent a long 30 minutes looking... >.< But thank you anyway <3
epilys 3y ago
So this is basically a *safe* optimization, since the index will always be valid and there's no need for the compiler to do a check and unwrap, panic. This is how unsafe {} should be used. Sometimes some things are true but the compiler can't know that. And here the unsafe {} means that it dereferences a raw pointer (the index that we know is valid). If the unsafe {} safety condition is valid, unsafe {} is, well, safe.
- someplaceguy 3y ago
  Furthermore, it's an optional optimization (you could just copy the code and replace the unsafe access with a safe one, if you're paranoid) and it's not like if you write it in C++ it will be any safer than Rust's unsafe?!

LoganDark 3y ago

Alright, and as a versioned link that'll be: https://github.com/rust-lang/rust/blob/7d8386f05cedf33c7475cbb44f84178df5919202/library/core/src/slice/mod.rs#L2781 https://github.com/rust-lang/rust/blob/7d8386f05cedf33c7475c... Thank you!

veber-alex 3y ago
You can get versioned link directly into rustdoc: https://doc.rust-lang.org/1.71.1/src/core/slice/mod.rs.html#2779 https://doc.rust-lang.org/1.71.1/src/core/slice/mod.rs.html#...
- LoganDark 3y ago
  I couldn't find any direct references to this anywhere, believe me I spent a long 30 minutes looking... >.< But thank you anyway <3

epilys 3y ago

So this is basically a *safe* optimization, since the index will always be valid and there's no need for the compiler to do a check and unwrap, panic. This is how unsafe {} should be used. Sometimes some things are true but the compiler can't know that. And here the unsafe {} means that it dereferences a raw pointer (the index that we know is valid). If the unsafe {} safety condition is valid, unsafe {} is, well, safe.

someplaceguy 3y ago
Furthermore, it's an optional optimization (you could just copy the code and replace the unsafe access with a safe one, if you're paranoid) and it's not like if you write it in C++ it will be any safer than Rust's unsafe?!