5 ms·

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 un

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.
  - reificator 9y ago
    But when you're debugging, you know where to focus your efforts. If 95% of your code touches the other 5%, then that 5% is probably pretty important and useful and hopefully fast. Spending some extra time to verify safety in exchange for speed/control is a small price to pay, and will pay dividends from the other 95% of code that doesn't have to be inspected so closely.
  - nickm12 9y ago
    No, the objective for Rust was never to be all the way safe. Rust gets much inspired by C++ and seeks to be a systems language where " there should be no room for a lower-level language between [it] and native machine code". If you want that, you need unsafe blocks. The intent is to use those blocks to build safe abstractions that can be used for the lion's share of your program.
    - mehrdadn 9y ago
      > "there should be no room for a lower-level language between [it] and native machine code" I hadn't heard this before, and I love it! This seems like a very nice way to define what a systems programming language is. :-)
madez 9y ago
I hope we don't settle for unsafe being okay forever. Right now, sometimes it is the right thing to do and there shouldn't be any regret. But in the future, I hope Rusts compilers become better. There are two things I consider necessary for that. First, that the Rust compilers become smarter in proving the safety of things by themselves. Second, that the Rust compilers become capable of verifying proofs given to them that show the safety of a given piece of code the compilers can't prove as safe on their own.
- Retra 9y ago
  The Rust compiler will not solve the halting problem. It is pretty trivial to write programs which are safe if and only if they halt. So 100% safe is simply absurd.
  - madez 9y ago
    That is trivially obvious, but writing a performant vector implementation is not solving the halting problem. Let me restrict it to the faintly weaker "I hope we don't settle for unsafe being okay forever where we can prove safety".
  - andrewflnr 9y ago
    You don't need to solve the halting problem just to verify an existing proof of a semantic property, nor to use smarter heuristics to avoid requiring such a proof. 100% safe is totally reachable, though I bet the syntax would be pretty hairy added to today's Rust.
    - jononor 9y ago
      Would need to get rid of C FFI, as that cannot be 'safe' in Rust?
      - andrewflnr 9y ago
        Hmm, good point. You'd have to extend the formal verification into the C code, at least. If you can do that, it might be easier to just write verified C.
derefr 9y ago
> Nope, unsafe does exactly what it says on the tin. Depends on how you interpret the name—whether it's referring to what it does (makes things no longer automatically safe), or whether it's referring to what the code inside it does. If you write only safe code, inside an unsafe{} block, then nothing unsafe is happening. Fewer compile-time static-analysis checks are happening, but if you manually verify that the code is "safe anyway" the way C/C++ programmers are forced to do, then you can declare that the code is safe, maybe with a comment like: // this is safe unsafe{ ... } That seems bizarre and contradictory, no? But it would seem less weird if it was: // this is safe unchecked{ ... } Of course, there's no reason you should be using an unsafe{} block for only safe code, so unsafe{} is usually a pretty good label for the content of the block.
- deleted 9y ago
  [deleted]
pjmlp 9y ago
Actually this problem was tackled in NEWP during the 60's. Section 8, UNSAFE mode http://public.support.unisys.com/aseries/docs/clearpath-mcp-17.0/pdf/86002003-407.pdf http://public.support.unisys.com/aseries/docs/clearpath-mcp-...

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.
- reificator 9y ago
  But when you're debugging, you know where to focus your efforts. If 95% of your code touches the other 5%, then that 5% is probably pretty important and useful and hopefully fast. Spending some extra time to verify safety in exchange for speed/control is a small price to pay, and will pay dividends from the other 95% of code that doesn't have to be inspected so closely.
- nickm12 9y ago
  No, the objective for Rust was never to be all the way safe. Rust gets much inspired by C++ and seeks to be a systems language where " there should be no room for a lower-level language between [it] and native machine code". If you want that, you need unsafe blocks. The intent is to use those blocks to build safe abstractions that can be used for the lion's share of your program.
  - mehrdadn 9y ago
    > "there should be no room for a lower-level language between [it] and native machine code" I hadn't heard this before, and I love it! This seems like a very nice way to define what a systems programming language is. :-)

madez 9y ago

I hope we don't settle for unsafe being okay forever. Right now, sometimes it is the right thing to do and there shouldn't be any regret. But in the future, I hope Rusts compilers become better. There are two things I consider necessary for that. First, that the Rust compilers become smarter in proving the safety of things by themselves. Second, that the Rust compilers become capable of verifying proofs given to them that show the safety of a given piece of code the compilers can't prove as safe on their own.

Retra 9y ago
The Rust compiler will not solve the halting problem. It is pretty trivial to write programs which are safe if and only if they halt. So 100% safe is simply absurd.
- madez 9y ago
  That is trivially obvious, but writing a performant vector implementation is not solving the halting problem. Let me restrict it to the faintly weaker "I hope we don't settle for unsafe being okay forever where we can prove safety".
- andrewflnr 9y ago
  You don't need to solve the halting problem just to verify an existing proof of a semantic property, nor to use smarter heuristics to avoid requiring such a proof. 100% safe is totally reachable, though I bet the syntax would be pretty hairy added to today's Rust.
  - jononor 9y ago
    Would need to get rid of C FFI, as that cannot be 'safe' in Rust?
    - andrewflnr 9y ago
      Hmm, good point. You'd have to extend the formal verification into the C code, at least. If you can do that, it might be easier to just write verified C.

derefr 9y ago

> Nope, unsafe does exactly what it says on the tin. Depends on how you interpret the name—whether it's referring to what it does (makes things no longer automatically safe), or whether it's referring to what the code inside it does. If you write only safe code, inside an unsafe{} block, then nothing unsafe is happening. Fewer compile-time static-analysis checks are happening, but if you manually verify that the code is "safe anyway" the way C/C++ programmers are forced to do, then you can declare that the code is safe, maybe with a comment like: // this is safe unsafe{ ... } That seems bizarre and contradictory, no? But it would seem less weird if it was: // this is safe unchecked{ ... } Of course, there's no reason you should be using an unsafe{} block for only safe code, so unsafe{} is usually a pretty good label for the content of the block.

deleted 9y ago
[deleted]

pjmlp 9y ago

Actually this problem was tackled in NEWP during the 60's. Section 8, UNSAFE mode http://public.support.unisys.com/aseries/docs/clearpath-mcp-17.0/pdf/86002003-407.pdf http://public.support.unisys.com/aseries/docs/clearpath-mcp-...