7 ms·

Semantically thats what the Rust std library linked list does as well https://doc.rust-lang.org/std/collections/struct.LinkedList.html https://doc.rust-lang.org

by bfrog 9y ago

Semantically thats what the Rust std library linked list does as well https://doc.rust-lang.org/std/collections/struct.LinkedList.html https://doc.rust-lang.org/std/collections/struct.LinkedList.... However that LinkedList implementation requires unsafe{} to be implemented. All unsafe really means is that the compiler isn't going to hold your hand, the usual memory ownership footgun is available at your discretion. unsafe shouldn't be this mythical thing you don't touch like people seem to think it is. If you need to escape the compilers very helpful guidance you can and should, but test thoroughly!

mehrdadn 9y ago
Going on a tangent, but I honestly think 'unsafe' might suffer from a naming issue. It should've been called 'unchecked' or 'unverifiable' or something that says the code is merely not verified to be safe, not that it is actually unsafe.
- j1f4 9y ago
  The word that I have seen in similar contexts is 'trusted', which I like and would have preferred -- the block has extra privileges and isn't machine verified. Some people tend to give 'trusted' an opposite reading when they first come across it, though.
  - mehrdadn 9y ago
    Oh yeah, 'trusted' would definitely give the opposite of the intended meaning! I had to read your comment twice just to get why you were calling it that.
  - lmkg 9y ago
    The problem with that word is it doesn't say who is doing the trusting, which is the crucial point. In fact, "trusted" can be used to describe both safe code and unsafe code. In the safe code, the programmer is trusting the compiler. In unsafe code, the compiler is trusting the programmer. Both code environments are "trusted," but the trust is being given to different parties.
- xenadu02 9y ago
  Nope, unsafe does exactly what it says on the tin. C# tackled this problem 15 years ago. I'm sure other languages (Haskell) did it even earlier. When to use unsafe is a judgement call. Each developer and team will have to set their own standards. Some people will abuse it. None of this is new. At first it scares people. They think this is the brave new world, using unsafe feels gross and backwards! Eventually they understand where it is and isn't appropriate. You might think "so what? Why even bother with a safe-by-default language?" Because it greatly restricts the problem space. Rather than being forced to examine every line of code for every possible bit of undefined behavior or every path of flow control for memory errors you only need to think really hard about edge cases inside the unsafe blocks. Simply by virtue of being a relatively small number of blocks of few lines the problem of safety and correctness becomes easier to understand. Easier to test. Easier to reason about. Unsafe is a tool. It's a dangerous tool so you should always wear your gloves and safety goggles. But when faced with a problem for which it is the best tool you should use it without regret.
  - mehrdadn 9y ago
    I'm not having a problem with it personally, I'm just saying that trying to educate the developers instead of addressing it on Rust's end seems like a potentially losing battle, as unfortunate as it might be.
  - gilbetron 9y ago
    All of C and C++ is basically unsafe, and we got a lot done with it! It's ok to use unsafe from time to time if you really need to :)
    - _sdegutis 9y ago
      Right but the hope was that Rust was all the way safe, not just most of the way safe. That’s it main niche. That’s why someone would choose it over C++. But if 95% of your code is safe and 5% of your code isn’t, and the safe 95% uses that unsafe 5% all over the place, it inherently makes the safe code an entry point into unsafe code, kinda-sorta making it unsafe too. So it ends up feeling like all the hard work to keep things safe was a waste.
- kbenson 9y ago
  That may be due to a quirk of how we use it in English (and maybe other languages, but I can't speak to that). For some reason, unsafe or not safe isn't always perceived as a logical negation as some other concepts usually are, and is instead parsed as opposite of safe. "Verified" seems to suffer from this less, but is also less strong in what it positively implies. Is it possible that the link to personal safety of the terminology is what provides the best positive connotation in terminology but also causes this unwanted ambiguity in negated interpretation? If so, that's an annoying catch-22...
- contravariant 9y ago
  To me it makes perfect sense that the keyword 'unsafe' disables safety mechanisms.
  - Narishma 9y ago
    But it doesn't disable anything. In fact, it does the opposite: it enables additional mechanisms which can't be checked by the compiler.
    - contravariant 9y ago
      That's a bit like saying that unlocking your front door adds an additional door to your house.
__s 9y ago
Agreed. Pointers are unsafe. References are safe, & almost powerful enough to make one think they don't need pointers. But if you find yourself needing pointers over references, they're there
kovrik 9y ago
> However that LinkedList implementation requires unsafe{} to be implemented. Can it be implemented without using unsafe? Do they have in plans to get rid of all unsafe from std?
- kinghajj 9y ago
  No on both counts, the entire point of "unsafe" is to form safe abstractions around unprovably safe code.
- viraptor 9y ago
  It can't. And there are many things std does that are in unsafe blocks. There's nothing wrong with that if you have a specific use case for it. (And wrap that functionality in a safe function)

by bfrog 9y ago

mehrdadn 9y ago

Going on a tangent, but I honestly think 'unsafe' might suffer from a naming issue. It should've been called 'unchecked' or 'unverifiable' or something that says the code is merely not verified to be safe, not that it is actually unsafe.

j1f4 9y ago
The word that I have seen in similar contexts is 'trusted', which I like and would have preferred -- the block has extra privileges and isn't machine verified. Some people tend to give 'trusted' an opposite reading when they first come across it, though.
- mehrdadn 9y ago
  Oh yeah, 'trusted' would definitely give the opposite of the intended meaning! I had to read your comment twice just to get why you were calling it that.
- lmkg 9y ago
  The problem with that word is it doesn't say who is doing the trusting, which is the crucial point. In fact, "trusted" can be used to describe both safe code and unsafe code. In the safe code, the programmer is trusting the compiler. In unsafe code, the compiler is trusting the programmer. Both code environments are "trusted," but the trust is being given to different parties.
xenadu02 9y ago
Nope, unsafe does exactly what it says on the tin. C# tackled this problem 15 years ago. I'm sure other languages (Haskell) did it even earlier. When to use unsafe is a judgement call. Each developer and team will have to set their own standards. Some people will abuse it. None of this is new. At first it scares people. They think this is the brave new world, using unsafe feels gross and backwards! Eventually they understand where it is and isn't appropriate. You might think "so what? Why even bother with a safe-by-default language?" Because it greatly restricts the problem space. Rather than being forced to examine every line of code for every possible bit of undefined behavior or every path of flow control for memory errors you only need to think really hard about edge cases inside the unsafe blocks. Simply by virtue of being a relatively small number of blocks of few lines the problem of safety and correctness becomes easier to understand. Easier to test. Easier to reason about. Unsafe is a tool. It's a dangerous tool so you should always wear your gloves and safety goggles. But when faced with a problem for which it is the best tool you should use it without regret.
- mehrdadn 9y ago
  I'm not having a problem with it personally, I'm just saying that trying to educate the developers instead of addressing it on Rust's end seems like a potentially losing battle, as unfortunate as it might be.
- gilbetron 9y ago
  All of C and C++ is basically unsafe, and we got a lot done with it! It's ok to use unsafe from time to time if you really need to :)
  - _sdegutis 9y ago
    Right but the hope was that Rust was all the way safe, not just most of the way safe. That’s it main niche. That’s why someone would choose it over C++. But if 95% of your code is safe and 5% of your code isn’t, and the safe 95% uses that unsafe 5% all over the place, it inherently makes the safe code an entry point into unsafe code, kinda-sorta making it unsafe too. So it ends up feeling like all the hard work to keep things safe was a waste.
kbenson 9y ago
That may be due to a quirk of how we use it in English (and maybe other languages, but I can't speak to that). For some reason, unsafe or not safe isn't always perceived as a logical negation as some other concepts usually are, and is instead parsed as opposite of safe. "Verified" seems to suffer from this less, but is also less strong in what it positively implies. Is it possible that the link to personal safety of the terminology is what provides the best positive connotation in terminology but also causes this unwanted ambiguity in negated interpretation? If so, that's an annoying catch-22...
contravariant 9y ago
To me it makes perfect sense that the keyword 'unsafe' disables safety mechanisms.
- Narishma 9y ago
  But it doesn't disable anything. In fact, it does the opposite: it enables additional mechanisms which can't be checked by the compiler.
  - contravariant 9y ago
    That's a bit like saying that unlocking your front door adds an additional door to your house.

__s 9y ago

Agreed. Pointers are unsafe. References are safe, & almost powerful enough to make one think they don't need pointers. But if you find yourself needing pointers over references, they're there

kovrik 9y ago

> However that LinkedList implementation requires unsafe{} to be implemented. Can it be implemented without using unsafe? Do they have in plans to get rid of all unsafe from std?

kinghajj 9y ago
No on both counts, the entire point of "unsafe" is to form safe abstractions around unprovably safe code.
viraptor 9y ago
It can't. And there are many things std does that are in unsafe blocks. There's nothing wrong with that if you have a specific use case for it. (And wrap that functionality in a safe function)