4 ms·

For me, the problem isn't `unwrap` vs. `expect`, it's that I can't statically guarantee that particularly mission-critical code never panics. I can be as caref

For me, the problem isn't `unwrap` vs. `expect`, it's that I can't statically guarantee that particularly mission-critical code never panics. I can be as careful as I want in writing panic-safe code, but there's no ergonomic and non-hacky way to ensure that I don't use third-party crates in a way that can possibly panic either.

nimih 4y ago
> I can be as careful as I want in writing panic-safe code, but there's no ergonomic and non-hacky way to ensure that I don't use third-party crates in a way that can possibly panic either. There's also no way to ensure those third-party crates don't enter an infinite loop; at some point, if you need to guarantee your program doesn't diverge, you need to either trust the libraries you're using to behave reasonably, or you need to audit them yourself. Removing `unwrap` wouldn't solve that problem, and given how easy it is to lint for, it doesn't even meaningfully contribute to its difficulty. As the GP and some of the other top level comments point out, `unwrap` is a genuinely useful tool to have in the std lib, so advocating for its removal (or that it was a bad choice to begin with, presumably hoping that future languages will avoid including amenities such as `unwrap`) seems like a poor design trade-off from where I stand.
- stouset 4y ago
  I am in no way agreeing with the idea that `unwrap` should be removed. I simply wish it were possible to assert statically at compile time that my application will not panic. Being unable to also detect infinite loops does not diminish this utility. I simply wish to reduce the likelihood that my mission-critical programs diverge as much as is possible. Being perfect is not a requirement.
  - rowanG077 4y ago
    Being able to statically assert your program does not panic is predicated on being able to detect infinite loops. For example a panic could be detected to occur after a loop which may or may not be infinite. If you can't detect infinite loops you also can't detect if the program will panic or not.
    - stouset 4y ago
      Why the insistence that this has to be perfect for it to be of any use? If the optimizer can prove it isn’t used and elides any code that might call it, great. If it can’t, I can rewrite my code to not use that function or call it in a way where the optimizer can make that guarantee. There are all sorts of useful things that technically depend on deciding the halting problem, but turn out to be pretty easily solvable for virtually all practical cases.
    - pdimitar 4y ago
      Disagreed, we can have good sanity checks while forgoing checks for infinite loops. It should not be an all or nothing affair. Improvements can be gradual.
      - rowanG077 4y ago
        What exactly is gradual about the question: "Can this program panic?". Either you are optimistic and allow any unproveable panics through and now you program will panic in practice. Or you are pessimistic and basically disallow any practical program. There are a lot of cases where a gradual approach works well. But something so fundamental and important like "Can this program panic?" is not one of those cases.
        pdimitar 4y ago
        I was addressing your odd fixation on not being able to prevent an infinite loop. That's not a real downside. We can still make progress in many other areas in the meantime.
        rowanG077 4y ago
        It's not about about being able to prevent an infinite loop. It's about being able to say this program really doesn't panic. Which is a very important property. For example the Linux Kernel requires Rust code to not panic. There was a lot of work done to ensure this was at all possible. And it wasn't to try and statically assert whether a piece of code panics. It was just disallow panics outright. Do you think these compiler developers just took that route because it's fun? Or because they are "oddly fixated on the halting problem"?

nimih 4y ago

> I can be as careful as I want in writing panic-safe code, but there's no ergonomic and non-hacky way to ensure that I don't use third-party crates in a way that can possibly panic either. There's also no way to ensure those third-party crates don't enter an infinite loop; at some point, if you need to guarantee your program doesn't diverge, you need to either trust the libraries you're using to behave reasonably, or you need to audit them yourself. Removing `unwrap` wouldn't solve that problem, and given how easy it is to lint for, it doesn't even meaningfully contribute to its difficulty. As the GP and some of the other top level comments point out, `unwrap` is a genuinely useful tool to have in the std lib, so advocating for its removal (or that it was a bad choice to begin with, presumably hoping that future languages will avoid including amenities such as `unwrap`) seems like a poor design trade-off from where I stand.

stouset 4y ago
I am in no way agreeing with the idea that `unwrap` should be removed. I simply wish it were possible to assert statically at compile time that my application will not panic. Being unable to also detect infinite loops does not diminish this utility. I simply wish to reduce the likelihood that my mission-critical programs diverge as much as is possible. Being perfect is not a requirement.
- rowanG077 4y ago
  Being able to statically assert your program does not panic is predicated on being able to detect infinite loops. For example a panic could be detected to occur after a loop which may or may not be infinite. If you can't detect infinite loops you also can't detect if the program will panic or not.
  - stouset 4y ago
    Why the insistence that this has to be perfect for it to be of any use? If the optimizer can prove it isn’t used and elides any code that might call it, great. If it can’t, I can rewrite my code to not use that function or call it in a way where the optimizer can make that guarantee. There are all sorts of useful things that technically depend on deciding the halting problem, but turn out to be pretty easily solvable for virtually all practical cases.
  - pdimitar 4y ago
    Disagreed, we can have good sanity checks while forgoing checks for infinite loops. It should not be an all or nothing affair. Improvements can be gradual.
    - rowanG077 4y ago
      What exactly is gradual about the question: "Can this program panic?". Either you are optimistic and allow any unproveable panics through and now you program will panic in practice. Or you are pessimistic and basically disallow any practical program. There are a lot of cases where a gradual approach works well. But something so fundamental and important like "Can this program panic?" is not one of those cases.
      - pdimitar 4y ago
        I was addressing your odd fixation on not being able to prevent an infinite loop. That's not a real downside. We can still make progress in many other areas in the meantime.
        rowanG077 4y ago
        It's not about about being able to prevent an infinite loop. It's about being able to say this program really doesn't panic. Which is a very important property. For example the Linux Kernel requires Rust code to not panic. There was a lot of work done to ensure this was at all possible. And it wasn't to try and statically assert whether a piece of code panics. It was just disallow panics outright. Do you think these compiler developers just took that route because it's fun? Or because they are "oddly fixated on the halting problem"?