Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior
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.
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.
> 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.
I don't know that there's whining about "having to handle errors" in principle, it's pretty clearly a complaint with the syntax and semantics of doing so
Some languages even make omitting error handling impossible! (e.g. Result sum types). None have anywhere near the amount of "whining" Go seems to attract
Codex-like agents are cool but as someone with even just a passing interest in compilers I absolutely hate this attempt at appropriating the word "codegen"
I don't necessarily disagree with the overall point, but I'm sad the article misses the big advantage to the sum-type solution. It is not just about "being able to collapse `res, err := func()` into `res := func()?`". With sum types you literally cannot access the Result's inner value without performing some kind of error handling. Even if you just `.unwrap()`.
> The point is, this function signature makes it impossible for us to access an invalid/uninitialized/null Metadata. With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer.
This announcement was only added to the README in early October[1]. In the meantime you can of course compile it yourself/grab a build from GH actions. I'm sure they would appreciate the testing, especially leading up to release :-)
reply