8 ms·

>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) A

by krisdol 11y ago

>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code does this when: * the developer believes the Option/Result can never be None/Err (oh come on, just wait until you refactor your code a bit one day and miss a spot) * the code is example code (I've had little luck finding "good" examples sprinkled about github) * the developer is lazy (see above) Allowing unsafe unwraps defeats a core purpose of rust, and the unwrap method shouldn't even exist in the API.

danieldk 11y ago
Allowing unsafe unwraps defeats a core purpose of rust, Definitely, but you can also still do this in Haskell (fromJust). But it's better than nullable types since you explicitly have call an unsafe method. (Assuming that you have set non-exhaustive pattern matching to be a warning/error.)
- steveklabnik 11y ago
  unwrap() is not unsafe in Rust, and I don't think Haskell has anything similar?
  - danieldk 11y ago
    Sorry for the confusion! I meant 'unsafe' as in partial (not safe for all inputs). Not as in Rust's unsafe keyword.
    - steveklabnik 11y ago
      Ah, right. It's really important in the context of Rust. :) People sometimes claim that unwrap() violates memory safety, which isn't true.
  - codygman 11y ago
    The definition in Rust's documentation[0] was this: let x: Option<&str> = None; assert_eq!(x.unwrap(), "air"); // fails The equivalent Haskell if unwrap throws a panic as the docs[0] seem to imply: λ> fromMaybe (error "panic!") Nothing *** Exception: panic! You could also do something like this if you don't mind dealing with the wrapped boolean value: λ> fmap (== "air") (Just "air") Just True and the failure case: λ> fmap (== "air") (Nothing) Nothing 0: https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap https://doc.rust-lang.org/std/option/enum.Option.html#method...
    - deleted 11y ago
      [deleted]
    - steveklabnik 11y ago
      Right, but it's still not unsafe. The stack unwinds, destructors get called. And I meant some notion of 'safety', not fromMaybe/fromJust.
markus2012 11y ago
I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.
- Manishearth 11y ago
  Care to explain why? Whatever unwrap provides can be done with a match+panic. Which is more explicit, but that's just splitting hairs -- unwrap is pretty explicit anyway.
  - valarauca1 11y ago
    I understand the anger but at the same time I don't. Overall unwrap() isn't good. Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That being said there are still good uses for it. The main _safe_ use for unwrap() I find is when dealing with an iterator of Results/Options (which seems to happen a lot). The pattern: .filter( |x| x.is_some() ) .map( |x| x.unwrap() ) Is safe, and I really don't know a more eloquent method of handling these operations.
    - cballard 11y ago
      In Swift you can solve this with a filterNone() method with an explicit type signature of [T?] -> [T], I assume that could also be implemented in Rust?
    - Manishearth 11y ago
      I'm not angry. > Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That's what the Rust community reads it as, mostly. I've seen it occur very infrequently in libraries (aside from example/benchmark/test/mocking code, of course). When it does its usually for really out of whack errors like poisoned mutexes, crashed threads, etc (mind you, these are for unwrapping error values, not options, but it's almost the same thing). Or for cases where it's known to be valid due to invariants that can't be expressed in the normal way. I did a quick grep of hyper, and the unwraps are almost all in "dev" code (tests/benchmarks/etc). The cases where they aren't are where there was an `is_some()` earlier (and due to some reasons it couldn't be restructured as a match, perhaps just because of rightward drift), or the "invariants" thing -- i.e. it often calls `<some url>.serialize_path().unwrap()`, which is OK, because hyper only ever deals with relative schemes (e.g. `http://` http://` and `https://` https://`, not `data:` or `mailto:` -- the latter two don't have paths), which is checked in the constructors, so this should NEVER panic. I didn't go through all the code, but in the main HTTP and HTTP2 code serialize_path was the only offender, which was one that was justified. I see it more often in applications. In the following cases: - Example applications in blog posts (because you want to explain something else, not spend too much time on error handling) - Slightly less out of whack errors which are weird enough that they should close the app - Normal errors which should close the app (e.g. "insufficient permissions" for a command line util, or a port-opening error on a network app). unwrap() prints out the error message so this is a very rudimentary form of error handling anyway. - Laziness, or often with a TODO. Not too common. So, it's mostly used in justifiable ways, and that's why it exists in the stdlib. It doesn't "wipe out" anything that the borrow checker provides (borrowchk and exhaustive match are two different things), and while it's a kludge if used often there are legitimate reasons to use it; enough reasons to have it in the stdlib. > I really don't know a more eloquent method of handling these operations. .filter_map(|x| foo(x)) :) (but yes, in general there are situations in which you know an Option is unwrappable, e.g. the serialize example above)
Gankro 11y ago
Just to clarify since `unsafe` is a special term in Rust: `unwrap` still checks for None and panics, it doesn't blindly assume it's valid. That said, I think you're too dismissive of "can never fail" assumptions. There's tons of places where something is optional in general, but based on various invariants you know it won't be. For instance, if you successfully acquire the first element in an array, you know you can get the last. If you legitimately believe that Option is always Some, I don't understand what you think you would otherwise put there? Gonna have your function return an Err if an internal invariant is broken? Gonna have callers actually check for that?
- krisdol 11y ago
  >Gonna have your function return an Err if an internal invariant is broken? Absolutely you should return an error. Whether the caller wants to panic or handle it or print unicorns should be left up to the caller, not your function. Functions should not be expected to tear down the thread in case of an error. Nothing that panics should belong anywhere in exported code
  - steveklabnik 11y ago
    The idea is that Err is good if it's a recoverable error, but if it's not recoverable, you should panic!. Most errors are recoverable. panic! is an antipattern in a library. Or at least, provide both a panic-ing and a non-panic-ing variant.
    - Gankro 11y ago
      We specifically recommend against providing panicing and non-panicking. This causes horrible combinatoric explosions. There's very few exceptions to this (array indexing being the major exception). We do of course recommend non-panicking, but there's a few cases where the burden of checking for errors is too high (indexing, refcell). We're actually in the midst of arguing whether to violate this convention and do it for RefCell: https://github.com/rust-lang/rust/issues/27733 https://github.com/rust-lang/rust/issues/27733
Manishearth 11y ago
> you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. Explicit vs implicit. In Rust/Haskell you are forced to do _something_ about the nullability. If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails. On the other hand, in Java, you can get an NPE where you didn't expect it because nulls move around easily and there's nothing in the type system to prevent that. That's the difference. > I'm surprised that so much new rust code does this Also, in my experience, unwrap() in Rust is mostly confined to irrecoverable errors in applications, and example blog posts (where the focus is on getting something done and not worrying about good error handling). > defeats a core purpose of rust What purpose? Whatever unwrap provides is still possible via a match+panic. Which is _more_ explicit, but they're both still explicit.
- peeters 11y ago
  > If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails. If you use Optional.get() without Optional.isPresent(), how is that any different? It's not as nice as pattern decomposition, but it's still fundamentally the same, and on top of that, transform functions are provided so that most of the time you can do null-safe operations.
  - Manishearth 11y ago
    The difference is that Optional itself can be null, and in Java everything can be null.
    - peeters 11y ago
      It can be, and it's annoying, but that's still a step forward. It's trivial for a good static checker to treat all Optional references as if they were annotated with your favorite @Nonnull annotation.
    - krisdol 11y ago
      But in Java you'd never use a library that calls System.exit when it reaches an unexpected null
bkv 11y ago
>Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you unwrap() is a convenience method that still uses exhaustive pattern matching and will panic if no value is present. The developer is making a conscious decision to panic in a not-present scenario, and on a case-by-case basis. The compiler is still doing it's job. This is different than java, where a get() on a non-present value is a runtime violation.
- oldmanjay 11y ago
  The distinction is there but the runtime behavior is not remarkably different. This feels more like a philosophical argument with no real purpose, to be honest.
  - bkv 11y ago
    If you don't think it's an important distinction then your real beef is that the developer can choose to panic in certain scenarios, which of course is silly when put in context.
kibwen 11y ago
> much to my disappointment as I'm just learning rust Then prepare to be disappointed by Haskell as well, where the equivalent function is called `fromJust`. :P Both languages discourage the use of these constructs, but they exist for good reasons.
- codygman 11y ago
  > Both languages discourage the use of these constructs, but they exist for good reasons. Curious, what are your good reasons for fromJust in Haskell?

by krisdol 11y ago

danieldk 11y ago

Allowing unsafe unwraps defeats a core purpose of rust, Definitely, but you can also still do this in Haskell (fromJust). But it's better than nullable types since you explicitly have call an unsafe method. (Assuming that you have set non-exhaustive pattern matching to be a warning/error.)

steveklabnik 11y ago
unwrap() is not unsafe in Rust, and I don't think Haskell has anything similar?
- danieldk 11y ago
  Sorry for the confusion! I meant 'unsafe' as in partial (not safe for all inputs). Not as in Rust's unsafe keyword.
  - steveklabnik 11y ago
    Ah, right. It's really important in the context of Rust. :) People sometimes claim that unwrap() violates memory safety, which isn't true.
- codygman 11y ago
  The definition in Rust's documentation[0] was this: let x: Option<&str> = None; assert_eq!(x.unwrap(), "air"); // fails The equivalent Haskell if unwrap throws a panic as the docs[0] seem to imply: λ> fromMaybe (error "panic!") Nothing *** Exception: panic! You could also do something like this if you don't mind dealing with the wrapped boolean value: λ> fmap (== "air") (Just "air") Just True and the failure case: λ> fmap (== "air") (Nothing) Nothing 0: https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap https://doc.rust-lang.org/std/option/enum.Option.html#method...
  - deleted 11y ago
    [deleted]
  - steveklabnik 11y ago
    Right, but it's still not unsafe. The stack unwinds, destructors get called. And I meant some notion of 'safety', not fromMaybe/fromJust.

markus2012 11y ago

I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.

Manishearth 11y ago
Care to explain why? Whatever unwrap provides can be done with a match+panic. Which is more explicit, but that's just splitting hairs -- unwrap is pretty explicit anyway.
- valarauca1 11y ago
  I understand the anger but at the same time I don't. Overall unwrap() isn't good. Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That being said there are still good uses for it. The main _safe_ use for unwrap() I find is when dealing with an iterator of Results/Options (which seems to happen a lot). The pattern: .filter( |x| x.is_some() ) .map( |x| x.unwrap() ) Is safe, and I really don't know a more eloquent method of handling these operations.
  - cballard 11y ago
    In Swift you can solve this with a filterNone() method with an explicit type signature of [T?] -> [T], I assume that could also be implemented in Rust?
  - Manishearth 11y ago
    I'm not angry. > Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That's what the Rust community reads it as, mostly. I've seen it occur very infrequently in libraries (aside from example/benchmark/test/mocking code, of course). When it does its usually for really out of whack errors like poisoned mutexes, crashed threads, etc (mind you, these are for unwrapping error values, not options, but it's almost the same thing). Or for cases where it's known to be valid due to invariants that can't be expressed in the normal way. I did a quick grep of hyper, and the unwraps are almost all in "dev" code (tests/benchmarks/etc). The cases where they aren't are where there was an `is_some()` earlier (and due to some reasons it couldn't be restructured as a match, perhaps just because of rightward drift), or the "invariants" thing -- i.e. it often calls `<some url>.serialize_path().unwrap()`, which is OK, because hyper only ever deals with relative schemes (e.g. `http://` http://` and `https://` https://`, not `data:` or `mailto:` -- the latter two don't have paths), which is checked in the constructors, so this should NEVER panic. I didn't go through all the code, but in the main HTTP and HTTP2 code serialize_path was the only offender, which was one that was justified. I see it more often in applications. In the following cases: - Example applications in blog posts (because you want to explain something else, not spend too much time on error handling) - Slightly less out of whack errors which are weird enough that they should close the app - Normal errors which should close the app (e.g. "insufficient permissions" for a command line util, or a port-opening error on a network app). unwrap() prints out the error message so this is a very rudimentary form of error handling anyway. - Laziness, or often with a TODO. Not too common. So, it's mostly used in justifiable ways, and that's why it exists in the stdlib. It doesn't "wipe out" anything that the borrow checker provides (borrowchk and exhaustive match are two different things), and while it's a kludge if used often there are legitimate reasons to use it; enough reasons to have it in the stdlib. > I really don't know a more eloquent method of handling these operations. .filter_map(|x| foo(x)) :) (but yes, in general there are situations in which you know an Option is unwrappable, e.g. the serialize example above)

Gankro 11y ago

Just to clarify since `unsafe` is a special term in Rust: `unwrap` still checks for None and panics, it doesn't blindly assume it's valid. That said, I think you're too dismissive of "can never fail" assumptions. There's tons of places where something is optional in general, but based on various invariants you know it won't be. For instance, if you successfully acquire the first element in an array, you know you can get the last. If you legitimately believe that Option is always Some, I don't understand what you think you would otherwise put there? Gonna have your function return an Err if an internal invariant is broken? Gonna have callers actually check for that?

krisdol 11y ago
>Gonna have your function return an Err if an internal invariant is broken? Absolutely you should return an error. Whether the caller wants to panic or handle it or print unicorns should be left up to the caller, not your function. Functions should not be expected to tear down the thread in case of an error. Nothing that panics should belong anywhere in exported code
- steveklabnik 11y ago
  The idea is that Err is good if it's a recoverable error, but if it's not recoverable, you should panic!. Most errors are recoverable. panic! is an antipattern in a library. Or at least, provide both a panic-ing and a non-panic-ing variant.
  - Gankro 11y ago
    We specifically recommend against providing panicing and non-panicking. This causes horrible combinatoric explosions. There's very few exceptions to this (array indexing being the major exception). We do of course recommend non-panicking, but there's a few cases where the burden of checking for errors is too high (indexing, refcell). We're actually in the midst of arguing whether to violate this convention and do it for RefCell: https://github.com/rust-lang/rust/issues/27733 https://github.com/rust-lang/rust/issues/27733

Manishearth 11y ago

> you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. Explicit vs implicit. In Rust/Haskell you are forced to do _something_ about the nullability. If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails. On the other hand, in Java, you can get an NPE where you didn't expect it because nulls move around easily and there's nothing in the type system to prevent that. That's the difference. > I'm surprised that so much new rust code does this Also, in my experience, unwrap() in Rust is mostly confined to irrecoverable errors in applications, and example blog posts (where the focus is on getting something done and not worrying about good error handling). > defeats a core purpose of rust What purpose? Whatever unwrap provides is still possible via a match+panic. Which is _more_ explicit, but they're both still explicit.

peeters 11y ago
> If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails. If you use Optional.get() without Optional.isPresent(), how is that any different? It's not as nice as pattern decomposition, but it's still fundamentally the same, and on top of that, transform functions are provided so that most of the time you can do null-safe operations.
- Manishearth 11y ago
  The difference is that Optional itself can be null, and in Java everything can be null.
  - peeters 11y ago
    It can be, and it's annoying, but that's still a step forward. It's trivial for a good static checker to treat all Optional references as if they were annotated with your favorite @Nonnull annotation.
  - krisdol 11y ago
    But in Java you'd never use a library that calls System.exit when it reaches an unexpected null

bkv 11y ago

>Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you unwrap() is a convenience method that still uses exhaustive pattern matching and will panic if no value is present. The developer is making a conscious decision to panic in a not-present scenario, and on a case-by-case basis. The compiler is still doing it's job. This is different than java, where a get() on a non-present value is a runtime violation.

oldmanjay 11y ago
The distinction is there but the runtime behavior is not remarkably different. This feels more like a philosophical argument with no real purpose, to be honest.
- bkv 11y ago
  If you don't think it's an important distinction then your real beef is that the developer can choose to panic in certain scenarios, which of course is silly when put in context.

kibwen 11y ago

> much to my disappointment as I'm just learning rust Then prepare to be disappointed by Haskell as well, where the equivalent function is called `fromJust`. :P Both languages discourage the use of these constructs, but they exist for good reasons.

codygman 11y ago
> Both languages discourage the use of these constructs, but they exist for good reasons. Curious, what are your good reasons for fromJust in Haskell?