3 ms·

I thought I was a pedantic non-idiomatic weirdo for doing this. But it really felt like the right way---and also that the language should make this pattern much

• mananaysiempre 1y ago
  > also that the language should make this pattern much easier Open sum types? I’m on the fence as to whether they should be inferrable.
• resonious 1y ago
  The "status quo" way erodes the benefit of Rust's error system. The whole point (in my mind at least) of type safe errors is to know in advance all if the failure modes of a function. If you share an error enum across many functions, it no longer serves that purpose, as you have errors that exist in the type but are never returned by the function. It would be nice if the syntax made it easier though. It's cumbersome to create new enums and implement Error for each of them.
  • klodolph 1y ago
    It’s not just syntax, there are semantic problems. Like, function 1 fails for reason A or B. Function 2 fails for A or C. You call both functions. How do you pattern match on reason A, in the result of your function? In Go, there’s a somewhat simple pattern for this, which is errors.Is().
    • Expurple 1y ago
      It's a tradeoff. When you have a "flat" union like `A | B | C` that makes it easy to pattern-match "leaf" errors, you give up the ability to add any additional context in function1 and function2. Although, there are workarounds like struct Error { leaf_error: A | B | C, context: Vec<String>, }