> But doesn't know how the return values will be used by the caller. What is perhaps lost in this is where Go says that values should always be useful? It does

> But doesn't know how the return values will be used by the caller. What is perhaps lost in this is where Go says that values should always be useful? It doesn't matter how it will be used by the caller. If I'm writing a function that can fail, no magic in existence can create a success object out of nothing, especially one that "should always be useful". At that point you're stuck either returning a nil pointer or a zombie object (along with the error). > Exactly the current way is what is said to be deficient, though. It's deficient because it's modelling the wrong (in the common case) thing. I'm saying if you're in the uncommon case and that actually _is_ what you're trying to model, then you still can. > A function of this type is naturally going to return a file every time because a file is always useful, even when there is failure. What? No. It's not useful if there is no file, if the error is "wtf, that file doesn't exist".