[garfij]

I spent about 6 years writing Go at $dayjob, and while what you're saying is technically true, idiomatically you also generally wanted to avoid scenarios where you would _want_ to observe them independently. The standard behavior is is if `err != nil`, the result should be ignored.

[randomdata]

That is incorrect. Idiomatic Go is abundantly clear that values must always be useful, even if all you have is the default value. Thus T must be useful regardless of the state of error, and vice versa. As such, they are free to be observed independently. That does not mean T and error cannot be in a relationship, but they are not dependents.

There being a relationship between T and error is common, but observance of error is only significant when the error is relevant. Quite often it is, but not always, and in the latter case you can, assuming the code is idiomatic, safely use T and ignore error. T must be useful, after all.

It may be possible to create a scenario where T is not useful when error is not nil if you really want to screw with people, but that code would decidedly not be idiomatic. Indeed, there is always some way to screw with people if you try hard enough, but that's really beyond this discussion.

The use of the Either monad here is trying to cover a dependency which doesn't exist.

[awused]

This is nonsense. This isn't about idiomatic Go or not, there is only one way to do things in Go, so a function doing things in that one way doesn't communicate anything to the caller. If you try to open a file, and the file doesn't exist, you have to return a useless nil pointer alongside the error and there is no way to magic up a "useful" T. Usually err != nil means T == nil, so trying to blindly use T assuming it's "useful" will panic and crash your program.

The idiomatic Go way to work around this is to write comments saying "sometimes T is non-nil even if err is non-nil, you need to handle this" and hoping your callers read your comments.

Funnily enough, your philosophy is far more true in a language with proper sum types. In Haskell/Ocaml/Rust, returning a tuple of (T, error) does mean that both T and error should both be "useful", because if they weren't the function would have chosen to return one or the other but not both. You're reading meaning into Go code where meaning can't be present, because there's no choice to be made, and ignoring languages where you actually can have the semantics you want Go to have.

[vlowther]

Anything that implements or consumes `io.Reader` or `io.Writer` would dispute that.

[awused]

Yeah, there are counterexamples, but the only way to know is to read the comments or source code of the function you're calling. (T, err) doesn't convey any useful information and, in the overwhelming majority of cases, err != nil means T is a meaningless default value that should be ignored or a null pointer.

By and large I think the stuff in this repo is too much and doesn't fit Go. I don't particularly want Go to pretend to be functional, but Either and Option at least would be nice to have in the stdlib and help prevent this exact issue where there are rare exceptions to normal practices. I don't see them getting widespread use without being part of the stdlib though. If Either/Option were common in Go but io.Reader was one of the few APIs returning (T, error), that would convey a lot more information.