On Thu, Aug 27, 2020 at 12:27 PM Robert Engels <reng...@ix.netcom.com> wrote: > > I think you just made the case... if you have existing code that declares a > concrete return type and you change that to an interface and nothing else you > are going to have problems.
I don't think anybody said "..change it to interface and nothing else". The problem is, even if you change it to include a nil-check it is still wrong. I agree that you should not do that. There is the "vet" tool that tells you about things you shouldn't do, and I think it would be useful if it warned against that. > > On Aug 27, 2020, at 12:11 PM, Jake Montgomery <jake6...@gmail.com> wrote: > > > > > On Thursday, August 27, 2020 at 10:45:52 AM UTC-4, burak serdar wrote: >> >> On Thu, Aug 27, 2020 at 6:12 AM 'Axel Wagner' via golang-nuts >> <golan...@googlegroups.com> wrote: >> > >> > On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com <targ...@gmail.com> >> > wrote: >> >> >> >> Because you then must remember about this specific case every time you >> >> cast potentially nil pointer variable to interface. Every time you must >> >> write `if x != nil { return x; } else { return nil; }` instead of just >> >> `return x;` >> > >> > >> > This is true, but that alone is not indicative of a problem. You have to >> > remember that `select` does a pseudo-random selection of cases everytime >> > you use it, that you can't write to nil-maps, that dereferencing a >> > nil-pointer might panic, that an index-expression might panic, that >> > integer-addition might overflow, that floating-point math has >> > counter-intuitive edge-cases, that init-functions run before main… you >> > have to remember a *lot* of things every time you need them. >> > >> > I don't want to sound dismissive (as I said, I do think there is obviously >> > *some* problem) but I don't run into cases where I would even be *tempted* >> > to do this. Like, in your example, you'd need to a) have a declared >> > pointer, b) would need to be oblivious to the fact on whether or not it's >> > nil and c) it would have to be an invalid value if so and d) it would have >> > to be a problem not caught by other means (e.g. returning a non-nil error >> > alongside it). And when I am tempted to do this, I just know that the >> > interface value will still be non-nil. And even when I don't, the most >> > trivial of testing catches the problem. >> > >> > Like, I'm not saying it *never* happens or even that it never happens *to >> > me*. But it seems very rarely cause significant problems and I don't >> > understand why people put it so high up their list of being confusing or >> > hard to remember. >> >> I saw this happen mostly after refactoring code to replace structs >> with interfaces. Functions start returning interfaces instead of >> concrete types, and there is no obvious indication in the code that >> might alert the potential problem. > > > Like Burak, once I was no longer a noob, this has rarely bitten me. In fact, > I literally can't remember it being a problem since I became proficient in > Go. It probably has, but not enough to stick with me. I also almost never > find myself using the `if x != nil { return x; } else { return nil; }` > pattern, so it is not a burden for me. > > I'm not going to argue whether Go got it right, or not, since a change at > this point is exceedingly unlikely. But, on a pragmatic level, two thing > struck me about your response. > > The first is the old adage: "Accept interfaces return concrete types." There > are many good reasons for violating this rule, but I hope all this > refactoring that involved changing functions that had concrete types, but > choose to return them as interfaces really thought about the justification > for breaking the advice. > > The second is that refactoring is always tricky and requires attention to > detail. A struct and interface are not the same thing, so this is not > zero-change transformation by definition. It seems like you should be very > aware that you are changing a function from returning a struct to returning > an interface, at the time. Maybe the first time this would bite you, but > after that it seems like it would become wrote to know that such a change > requires a tiny bit of extra thought. > > Admittedly these are not firm technical arguments ... just my experience and > opinion. > > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/99a93de9-5dbc-474a-b0c9-906a8ae2cbaeo%40googlegroups.com. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/EEC803AB-E5A9-4274-9CE6-6DB2A340F29B%40ix.netcom.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2RqreB7eEZntVZCc2nM7n5Nfb%3DWkeZ3uO7L57JWmtTSCKbQ%40mail.gmail.com.