Maybe I misunderstood this
>
> The first is the old adage: "Accept interfaces return concrete types."
No interface based design would have you declare a concrete type as the return
value - so it must be declaring a interface return and returning a concrete.
Which is what was being argued against.
> On Aug 27, 2020, at 1:36 PM, burak serdar <bser...@computer.org> wrote:
>
> 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/409A26B8-6F3A-4FA5-BED7-89AC7745BCCB%40ix.netcom.com.
