On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney <d...@cheney.net> wrote: > > > 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. >
Great point. Why does gc implement it that way, then? And does it hurt, that gc implement it that way? The contract does not contain anything about the iteration order, so why did we add that code and CPU time to explicitly randomize it, instead of just letting buggy code be buggy and blow up at some point with hard to debug errors? This seems to be essentially the argument you are making, so why does it, seemingly, not apply to randomized map iteration in gc? > > 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. > No, it is not. The contract is the same. I'm sorry to be a stickler here, but I really don't see why this point is so elusive. I am not suggesting adding a "if an error is returned, the other return values will have their zero value" to my godoc. > B, it encourages people to be clever and try to avoid the error checking > idiom. > I legit don't see how, given that this is not a rule. I also don't do it with any kind of strictness that would allow people to rely on it. > C, doesn't work for all return values, only the pointer shaped ones. > I disagree. An empty string or a 0 or whatever is *still* a much more telling symptom to debug than *some* string/integer/whatever, especially if it's an invalid value (and if it isn't; why is would we even talk about it). But anyway, yes, I mostly do this with pointers, but *so what*? Why throw the baby out with the bathwater? Again, this is not part of any API. This is not an all or nothing thing. This is a safety net for people coding bugs and it's totally fine if it is there sometimes and not there at other times (and you even argue yourself that it shouldn't, to "keep people on their toes"). > > > > 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.
