7 ms·

1. That is a global static relationship rather than a local one dynamic one, which is the sense in which Go users use wrapping. 2. Idiomatic go type erases err

• alexchamberlain 1y ago
  > That is a global static relationship rather than a local one dynamic one, which is the sense in which Go users use wrapping. In practice, the error type will be defined quite close to where the conversion is applied, so the static nature of it doesn’t feel too big.
• NobodyNada 1y ago
  `map_err` does not need to be type-directed; you can use an arbitrary function or closure. An enum variant can be used as a function mapping from the variant type to the error type, but we can do any arbitrary transformation: .map_err(|e| format!("Failed to read file: {e}")?; But the "idiomatic Go" way of doing things sounds a lot closer to anyhow in Rust, which provides convenience utilities for dealing with type-erased errors: use anyhow::{Result, Context}; fn foo() -> Result<()> { let data = std::fs::read("/some/file").context("Failed to read file")?; // ... }
  • masklinn 1y ago
    Yes, I know that, but the argument (which, again, I called dubious) is that in both cases it's much easier to do just e.g. fn foo() -> Result<()> { let data = std::fs::read("/some/file")?; // ... } whereas the current morass of Go's error handling means adding wrapping is not much more of a hassle. But of course even if you accept that assertion you can just design your version of `?` such that wrapping is easier / not wrapping is harder (as it's still something you want) e.g. make it `?"value"` and `?nil` instead of `?`, or something.