Sorry, I wasnt specific in that part. When I say 'rust style' Im really just referring to a union type of `result | error`, with a way to check the state (eg isError and isResult) along with a way to get the state (eg getResult and getError). Optionally '?' and '!' as sugar.
That said, the other responder points out why the sum type approach is not favored (which is news to me, since like I said I havent followed the discussion)
To be fair Rust doesn't have sum type it has enums, which I feel like you could do in Go, but I haven't read the arguments.
In Go, values are to be always useful, so `result | error` would be logically incorrect. `(result, result | error)`, perhaps – assuming Go had sum types, but that's a bit strange to pass the result twice.
Just more of the pitfalls of it not being clear how Rust-style applies to an entirely different language with an entirely different view of the world.
It's an interesting idea. Right now, you can do something like this:
Then, presumably, a T|error sum type would be a specialization of the any type that would allow you to safely eliminate the default arm of the switch statement (or so I would like to think -- but the zero value issue rears its ugly head here too). Personally, I'd also like to see a refinement of type switches, to allow different variable names for each arm, resulting in something like the following hypothetical syntax: However, there's no real syntactic benefit for error handling to be found here. I like it (I want discriminated unions too), but it's really tangential to the problem. I'd honestly prefer it more for other purposes than errors.