An idiomatic Go function will ensure that T is always useful, regardless of the error state. At very least it will return the zero value for T, to which the Go maxim states: Make the zero value useful. From the perspective of writing the function returning (T, error), there will always be four states, with T and error being independent of each other. Anything else is faulty design.
Unfortunately, some early Go code written before things were well understood left T to be undefined given certain error states, so one cannot assume that T will be valid in all cases for all functions. This does mean that the caller's perspective can only reliably consider three states absent of diving deeper (e.g. reading the documentation).
By 'implicit' I assume you mean 'by convention'? I say this because unless I've misread the go spec (and that's a distinct possibility), function returns are either a single value or a tuple and there is no specification on tuple returns and mutually exclusive values.
FWIW, I mostly like go and work with it practically every day. I absolutely loathe it's ideas on error handling. I have quite strong feelings on the subject that aren't fit for polite discussion.
Its idea is simply that error is just state like any other. I find that to be quite reasonable – and something I miss dearly when I work in other languages which try to get overly fancy to try and hide that fact. There is nothing special about errors. The machine certainly has no concept of errors. Why does it need special constructs?
Bad practices like assuming T and error are dependent do break the ideas, but a language can only hold the hands of poor developers so much. Someone determined enough to write bad code will do so in any language.
Realistically, if there is a handling problem, it is a problem for all values of all kinds. Every single problem one can point to about handling errors is also a problem when handing names, email addresses, random numbers, etc. To single it out as an error handling problem specifically is flawed.
> I have quite strong feelings on the subject that aren't fit for polite discussion.
I'd love to hear more. You won't hurt my feelings. Getting worked up about a programming language discussion is illogical.
Sure, product types are the wrong shape for several different problems, not just error handling. Go doesn't have any other shape of user defined types so... too bad you're just stuck with something the wrong shape. Errors are an example where it's more obvious to more people.
Also the machine actually does know about errors, for example the x86-64 architecture defines several kinds of faults, for which provided handlers will be executed, Linux actually deliberately makes it impossible to run such fault handlers after any other way to reboot has proved ineffective, then trips a fault, because it knows an x86 CPU which can't run the fault handlers despite a fault will give up and reboot, which is what Linux was trying to achieve anyway. ARM has error interrupts, POWER has layers of nested error handling.
While that is true, the shape has no bearing on the handling problem. Go could have every type shape-defining feature ever conceived and it would still have the very same handling problem – for errors and everything else.
> Errors are an example where it's more obvious to more people.
In my experience, the vast majority of bugs I encounter in the real world are related to the handling problem of non-error values. That is where it is most obvious, and not just in Go. I expect errors only get talked about because it is fashionable to repeat what someone else said, not because anyone put any thought into it.
> Also the machine actually does know about error
Only within the confines of one human interpretation of how the machine functions, just as is the case for code. The machine itself has no such concept. It doesn't have awareness that a given state is an error or a rainbow.
