In cases where it's valid, you use a type that makes it valid. Much of the point of having a type system is that the return type tells you exactly what the valid things for the function to return are.

Having an explicit declaration of which functions might return both a result and an error and which functions will definitely return one or the other but not both makes your code easier to understand and work with. As it stands, I would bet that most Go programmers ignore the possibility of returning both a result and an error even in functions that do it deliberately, because the idiomatic thing a function with that signature does is return one or the other but not both.

If anyone has an example of this being a pattern used somewhere that they think is good I'd love for them to share it.

Probably bad example off the top of my head: You're returning say a "User" which has a user_id, name, and a list of recent purchases.

If the function errors out on the recent purchases, the caller may prefer that it still gets back a "User" object with the other information filled in, and then an "error" also set so the caller knows the information isn't complete.

The contract is always right … how well it is expressed through language mechanics is maybe another way to contrast things here. (FWIW I think Go could tighten up a few things - dropping or shadowing errors is a bit worrying - but I’m fairly convinced sum vs product is a little too harsh of a reduction; a useful distinction but not a complete one.)

That's why I wrote: Yes there are times when those are valid returns, but easily 99% of the time they're not. The type system should be able to represent both ways.

The golang type system can _already_ encode the case you're talking about, and that should stay. My complaint is that is the _only_ case it can represent, it cannot represent the more common case.