[Huggernaut]

I agree. I would be extremely surprised and look for refactoring opportunities if I came across a function that returned a success case that was expected to be used in combination with an error value.

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.

[kadoban]

The only case I can think of is partial success.

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.

[xh-dude]

A reduced version of this is maybe where Go and Rust have a pretty similar contract for things that “Read” and lean hard into permitting partial success. Both allow for some relatively sharp edge cases with zero-sized reads.

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.)