> On 1 Apr 2017, at 10:41, Axel Wagner <axel.wagner...@googlemail.com> wrote: > > So… Given that I'm not talking about modifying any contract - see a) in my > previous message - but just making an effort that I'm not contractual bound > by, I am not sure how I am supposed to read this. Is this an argument for not > being helpful? Because I don't quite see how your point invalidates that. Or > is it an argument for being hurtful? Which I also don't really see, as I'm > not talking about any change in contract. > > Like, I legit starting to doubt my sanity here; I don't see how I can > actually be any clearer about how I do not intend to change anything about > the "if a non-nil error is returned, assume the returns are invalid" rule. > The question is "how is it hurtful, if I then also add an extra layer of > defense against people violating that contract"?
But why? Why encourage people to be reckless. IMO this is difference between map ordering during iteration being undefined, which it is, rather than guaranteed to be random, which is not. Both are contracts with the same result to the casual user -- map iteration is unpredictable, but by not guaranteeing that the order will be random, it prevents people relying on the side effect. This is the argument I'm making now, yes, you could go to effort to make sure that some of the values you return are nil so that they explode as soon as someone forgets to check an error, but you probably shouldn't because A, this is providing a stronger contract than necessary. B, it encourages people to be clever and try to avoid the error checking idiom. C, doesn't work for all return values, only the pointer shaped ones. > > Are you trying to say that I'm training them to not adhere to the contract? > Because I don't see how; it's blowing up either way, just, in one case the > blowup might be easier to detect and debug. > > I respect your opinion and I do agree, but we just seem to be talking about > different things… anyway. Sleep, for now. > >> On Sat, Apr 1, 2017 at 1:09 AM, Dave Cheney <d...@cheney.net> wrote: >> I think the simpler contract is to give no guarantee whatsoever of the state >> of the other return values in the presence of an error. >> >> It's a simple, clear, and most importantly consistent contact. >> >> To guarenteed that in the presence of an error the values that can be >> respresented by nil _will_ be nil is less consistent, and more importantly >> encourages people to not check error by substituting their own ad-hoc tests >> like testing if a return value is nil, implying an error. >> >> -- >> 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.
