[slowpoke]

>After all, if the error is true the result is invalid.

False. A returned error does not necessarily mean the result is invalid. It could also mean something went wrong and you only have a partial result (which can be useful). Or that whatever the function returns doesn't directly have anything to do with what the function does (mostly for functions which are called for their side effects).

An example I can spontaneously come up with is the very common Writer interface. Its Write() function returns an int and an error. The int denotes the amount of bytes written to whatever is implementing the interface. This value is useful regardless of whether there was an error or not. You don't want an OR here. You want an AND.

Besides, what you are proposing could easily be done in Go. After all, errors are only things implementing the Error interface. But that doesn't really add to code clarity. Also, your code snippet isn't that different from how Go error handling looks right now. I don't see the practical difference.