> On 1 Apr 2017, at 11:02, Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > >> 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?
Map ordering is undefined by the spec, some implementations choose to randomise the order but this is an implementation detail. > >> >> 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. No, it's not. One is "in the presence of an error, the other values returned are undefined", your contract is "in the presence of an error, the others values returned will be their respective zero value" > >> 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. In your scheme, if there is an error, the function func NewT() (*T, error) I could check if the value of T is nil, or the error is nil, to confirm the error condition. > >> 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 now you've introduced the problem that sometimes func f() (int, error) might return 0, but you don't know if that's a valid value, or the zero value--without checking the error value, so your back to square one. > > 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"). People will build castles on your foundation of unexpected side effects. You want to avoid that. > >> >> >>> >>> 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.
