On Thu, Jun 27, 2019 at 8:51 AM Axel Wagner
<axel.wagner...@googlemail.com> wrote:
>
> It's been discussed a bunch of times - the main argument against remains that
> "nil" is not a special value and can be a perfectly reasonable implementation
> of an interface. For example, `sort.StringSlice(nil)` is a perfectly fine
> implementation of `sort.Interface` (the same, of course, for any other slice
> type you might implement `sort.Interface` for yourself). I.e. there is
> nothing *inherently* wrong putting a `nil` concrete value into an interface
> to make a non-nil interface. And as vet errs on the side of caution (and
> also, because TBQH it seems useless to specifically initialize a slice with
> an empty slice just to satisfy vet), there shouldn't be vet-checks with
> (likely) false positives.
>
> I think it *might* be possible to write a careful vet-check that avoids false
> positives and can still help catch some of the bugs. If you find an
> assignment of a definitely-nil-value to an interface, you could check the
> methods of that concrete type whether they panic when the receiver is nil
> (i.e. if they dereference it). This wouldn't have false positives, but should
> catch most interesting and simple cases.
I agree with what you said about false positives. Some of them, like
the one you gave above about the sort.StringSlice can be avoided.
To give some context on why this is so annoying:
I have a function that simply returns the next item in chain:
func (a X) Next() *Item {
return a.Next
}
...
if a.Next()==nil {
...
}
Later, this function is converted to use an interface instead of the
concrete type:
func (a X) Next() Intf {
return a.Next
}
Now the if a.Next()==nil {} no longer works. It has to be changed to:
func (a X) Next() Intf {
if a.Next==nil {
return nil
}
return a.Next
}
So if vet could check :
- function returns an interface Y
- there is a return X where X is not of type Y and is a reference
- X is not assigned a value in at least one code path
- there are no nil-checks for X
then it is likely that function will mask a nil-return.
>
> If that sounds interesting, I would recommend trying to implement that as a
> tool out-of-tree, to give the community opportunity to test it out. If you
> base it on the analysis package, it would be easy to integrate into other
> tools (and maybe eventually vet) when the time comes :)
>
> On Thu, Jun 27, 2019 at 4:20 PM Burak Serdar <bser...@ieee.org> wrote:
>>
>> This happened to me more than once, and not only with errors.
>>
>> For a function that is declared to return an interface, if you return
>> a nil-pointer with a type other than that interface, the returned
>> interface is not nil.
>>
>> Here's an example:
>>
>> https://play.golang.org/p/dpd76zyN9Fv
>>
>> I think go vet should warn about this case. What do you think?
>>
>> --
>> 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/CAMV2RqrpdCa4t6VrBrkbU%3DrbdNhC_oz%2BusTD9PA6VgCb%3D2SXJw%40mail.gmail.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqq8AaEK4e54JxyBfCzjxzT6zqXpyi3ZUGGHcTKUx9KbhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
