> It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case.Based on what? We have come to see that it is beneficial to make zero values useful. In fact, Go Proverbs even says so. Likewise, we have learned it is useful to return the zero value when you have an error. Most commonly, this means returning nil, which is packed full of all kinds of useful information. Therefore, the T value can be expected to useful if the code is idiomatic.
I'd love to see some real-world code you think is idiomatic, but doesn't return a useful T value when there is an error.
> If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise
This is not at odds with that. This merely warns that not all code you may call will be idiomatic. In fact, if I recall correctly, doesn't os.Open (maybe os.Create) return an invalid file handle in some error cases? The standard library is old and what helped us eventually see what is idiomatic. It is decidedly not idiomatic for the most part. If you rely on a function being written idiomatically, then you are going to run into trouble, as that is not a guarantee (unless the documentation provides such a guarantee).
But in the case of this Either wrapper, it explicitly states it is for use with idiomatic code, not any old code you can throw at it.