I agree (as I said). But that wasn't the question. The question was, whether it is hurtful, for me, as the author of a function, to a) not give that guarantee, but b) still do my best do return obviously blowing up values (under the assumption that the users of my packages, me included, are not fallible and will thus, potentially, ignore that non-guarantee), even if that adds an extra if or two.
Notably, it's also not really the question whether it *helps *if I do; the specific claim was, that it *hurts, *which I do strongly disagree with. However, I would be interested to hear reasons why my thinking on it being at least somewhat helpful is wrong. On Sat, Apr 1, 2017 at 12:43 AM, Dave Cheney <d...@cheney.net> wrote: > My position is the caller cannot make any assertion about the state of the > other values returned until they have checked the error. If the error was > non nil then nothing can be said about the state of the other values > returned. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
