5 ms·

I don't use Go, but I actually like Go's error handling and I think multiple return values is a better solution than any other language I've used. So much so, I

I don't use Go, but I actually like Go's error handling and I think multiple return values is a better solution than any other language I've used. So much so, I've basically adopted it in my c++ code using std::pair. Errors are a value, and the abstraction over that is unnecessary in my opinion. Rust's result type is just syntactic sugar around the multiple return value approach. I don't care for the syntactic sugar, and doing many things in few lines of code isn't valuable to me, but I suspect this is why people love rust's error handling.

masklinn 1y ago
[flagged]
- unclad5968 1y ago
  I'm certainly open to discussion, but your comment doesn't really have any substance to respond to.
  - aystatic 1y ago
    You've managed to miss the entire point of using a union: the value is either a success payload or an error value, never both. You can't encode that mutual exclusivity if you return a std::pair or std::tuple. That's exactly why std::expected, std::variant, or Rust enums exist, to make that constraint explicit in the type system.
    - unclad5968 1y ago
      Yeah that makes sense. My assertion was definitely incorrect, but also not really what I was trying to describe. My argument is that they are not conceptually different. The implementation is different, in that a union occupies the same memory for either value, but whether they occupy the same memory or not, you have to check the value to determine that is an error. The compiler can force you to handle multiple return values the same way it can force you to check a variant.
      - masklinn 1y ago
        > My argument is that they are not conceptually different. Your argument is nonsensical on its face, it could not be a more different way to compose types. > The implementation is different It's also largely irrelevant, the commenter above makes no mention of the memory state, because that's not the point. The point is that the states are exclusive. > The compiler can force you to handle multiple return values the same way it can force you to check a variant. No it can not, specifically because it's a product type (or it would be if it were a type anyway), and there is no relation between the fields. At most you can apply some mangy heuristics and hope they don't fuck up to often. A sum type tells you in no uncertain terms that you can have only one of the types at any given time. And that's not accounting for the fact that a result is a reified value, which an MRV is not, so it can be passed around and manipulated as any value, and can be operated on as a thing of its own.
  - masklinn 1y ago
    > I'm certainly open to discussion That is certainly not how your comment comes across.
hmry 1y ago
> Rust's result type is just syntactic sugar around the multiple return value approach That's really not true. Multiple return values means you always need to return some return value and some error value, even if they are dummy values (like nil). While a result type / sum type genuinely only contains one branch, not the other. If you had a language that didn't have nil, it would genuinely be impossible to emulate sum type like behavior on top of multiple return values. It serves as an escape hatch, to create a value of some type when you don't actually have a meaningful value to give. std::variant / std::expected / std::optional aren't syntactic sugar for std::pair either.

masklinn 1y ago

[flagged]

unclad5968 1y ago
I'm certainly open to discussion, but your comment doesn't really have any substance to respond to.
- aystatic 1y ago
  You've managed to miss the entire point of using a union: the value is either a success payload or an error value, never both. You can't encode that mutual exclusivity if you return a std::pair or std::tuple. That's exactly why std::expected, std::variant, or Rust enums exist, to make that constraint explicit in the type system.
  - unclad5968 1y ago
    Yeah that makes sense. My assertion was definitely incorrect, but also not really what I was trying to describe. My argument is that they are not conceptually different. The implementation is different, in that a union occupies the same memory for either value, but whether they occupy the same memory or not, you have to check the value to determine that is an error. The compiler can force you to handle multiple return values the same way it can force you to check a variant.
    - masklinn 1y ago
      > My argument is that they are not conceptually different. Your argument is nonsensical on its face, it could not be a more different way to compose types. > The implementation is different It's also largely irrelevant, the commenter above makes no mention of the memory state, because that's not the point. The point is that the states are exclusive. > The compiler can force you to handle multiple return values the same way it can force you to check a variant. No it can not, specifically because it's a product type (or it would be if it were a type anyway), and there is no relation between the fields. At most you can apply some mangy heuristics and hope they don't fuck up to often. A sum type tells you in no uncertain terms that you can have only one of the types at any given time. And that's not accounting for the fact that a result is a reified value, which an MRV is not, so it can be passed around and manipulated as any value, and can be operated on as a thing of its own.
- masklinn 1y ago
  > I'm certainly open to discussion That is certainly not how your comment comes across.

hmry 1y ago

> Rust's result type is just syntactic sugar around the multiple return value approach That's really not true. Multiple return values means you always need to return some return value and some error value, even if they are dummy values (like nil). While a result type / sum type genuinely only contains one branch, not the other. If you had a language that didn't have nil, it would genuinely be impossible to emulate sum type like behavior on top of multiple return values. It serves as an escape hatch, to create a value of some type when you don't actually have a meaningful value to give. std::variant / std::expected / std::optional aren't syntactic sugar for std::pair either.