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 <javascript:>> wrote:
> >
> > On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com <targ...@gmail.com
> <javascript:>> 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.
