3 ms·

While sum types would be a welcome addition in general, summing an error is logically erroneous. It is an independent state. The question mark is interesting,

While sum types would be a welcome addition in general, summing an error is logically erroneous. It is an independent state. The question mark is interesting, but as the try proposal discovered, how do you solve the leaking problem? That doesn't have a good solution yet.

valenterry 3y ago
> Summing an error is logically erroneous. It is an independent state. Doesn't compute for me. Care to explain?
wruza 3y ago
In practice it’s either-or in “error handling”, because that’s when you decide what to do and not do next.
- randomdata 3y ago
  Not true. As zero values are to be useful, one should never have to observe the error state unless the error is significant to the caller for some reason. Sometimes the error is significant. Sometimes it isn't. That depends on what the caller's needs are. Summing the error makes assumptions about the caller that may or may not be true. That is a bad API design.
  - mplanchard 3y ago
    Yes this is why you can just operate on the non error value (with map), immediately propagate the error (with ?), just operate on the error value (with map_err), or ignore it completely (eg by converting it to an option or using something like unwrap_or_else). Errors in Rust are still just possibly present values: they’re just wrapped in an interface (a sum type) that forces you to be explicit about your intent to ignore, handle, or propagate the error.
    - randomdata 3y ago
      Propagation suffers from the leaking problem. Rust has solutions for that, but it's not clear how that translates to Go, hence why the "try" proposal failed. I'm sure there is some solution out there, but nobody has come up with a good one. It turns out if nobody does the work, the work doesn't get done. Again, needing to be explicit about your intent to do anything with an error is faulty. The values are not dependent. Just because some languages have gotten it wrong doesn't mean they all should.
      - mplanchard 3y ago
        What you're saying doesn't make sense to me, and I also don't know what you're referring to by the leaking problem. I don't see how the choice of being explicit or non-explicit about errors is "faulty." Plenty of languages choose to use exceptions and maximize your ability to ignore errors, while others force you to deal with (in some way) the fact that an operation is fallible. Neither of these is "wrong," in my opinion, but they do offer different tradeoffs and ergonomics. I'm not sure why you say that the values of a sum type must be "dependent," or what you mean by that. Maybe/Option is a sum type of Nothing or Some<T>. There's no dependency there. If my webserver can return JSON or XML, I might represent that with a sum type holding either a JSON object or an XML tree, but there's no dependency between those two things that I can see.
      - valenterry 3y ago
        What is the "leaking problem"?

valenterry 3y ago

> Summing an error is logically erroneous. It is an independent state. Doesn't compute for me. Care to explain?

wruza 3y ago

In practice it’s either-or in “error handling”, because that’s when you decide what to do and not do next.

randomdata 3y ago
Not true. As zero values are to be useful, one should never have to observe the error state unless the error is significant to the caller for some reason. Sometimes the error is significant. Sometimes it isn't. That depends on what the caller's needs are. Summing the error makes assumptions about the caller that may or may not be true. That is a bad API design.
- mplanchard 3y ago
  Yes this is why you can just operate on the non error value (with map), immediately propagate the error (with ?), just operate on the error value (with map_err), or ignore it completely (eg by converting it to an option or using something like unwrap_or_else). Errors in Rust are still just possibly present values: they’re just wrapped in an interface (a sum type) that forces you to be explicit about your intent to ignore, handle, or propagate the error.
  - randomdata 3y ago
    Propagation suffers from the leaking problem. Rust has solutions for that, but it's not clear how that translates to Go, hence why the "try" proposal failed. I'm sure there is some solution out there, but nobody has come up with a good one. It turns out if nobody does the work, the work doesn't get done. Again, needing to be explicit about your intent to do anything with an error is faulty. The values are not dependent. Just because some languages have gotten it wrong doesn't mean they all should.
    - mplanchard 3y ago
      What you're saying doesn't make sense to me, and I also don't know what you're referring to by the leaking problem. I don't see how the choice of being explicit or non-explicit about errors is "faulty." Plenty of languages choose to use exceptions and maximize your ability to ignore errors, while others force you to deal with (in some way) the fact that an operation is fallible. Neither of these is "wrong," in my opinion, but they do offer different tradeoffs and ergonomics. I'm not sure why you say that the values of a sum type must be "dependent," or what you mean by that. Maybe/Option is a sum type of Nothing or Some<T>. There's no dependency there. If my webserver can return JSON or XML, I might represent that with a sum type holding either a JSON object or an XML tree, but there's no dependency between those two things that I can see.
    - valenterry 3y ago
      What is the "leaking problem"?