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.
