One thing to be clear: It is very different if we are talking about "emit a
warning if a value is known to be nil" and "emit a warning unless a warning
is known not to be nil". The former seems fine to me - it is IMO fine for
this code to cause a vet-failure:
var x *int
y := *x
What I'm opposing is the original idea, for this code to cause a
vet-failure:
func (x *int) { *x }
Importantly, whether or not a value is `nil` is *always* going to be a
heuristic <https://en.wikipedia.org/wiki/Halting_problem>.
If we complain about "known to be nil", every finding will always be a bug.
I don't think it's objectionable to find them statically.
If we complain about "not known not to be nil", a significant number of
findings will be non-bugs, leading to changes as OP suggested. So, I'm
assuming that's the situation we are talking about.
On Thu, Mar 24, 2022 at 9:40 AM Sam Hughes <sam.a.hug...@gmail.com> wrote:
> @axel, it my feel counter-intuitive, but a possible runtime panic
> converted to a compiler error is an increase in how robust the code is.
>
Of course. But that's not what we are talking about. We are converting
*some* runtime bugs into compiler errors (really, vet checks, we can't fail
to compile because of backwards compatibility).
But most of them, where it's not clear from the code that a particular
pointer is going to be nil, will get the treatment suggested by OP. Which
ends up exploding the state-space of possible behaviors of a program,
making it exponentially harder to know what it's doing.
That's IMO the less intuitive thing. People tend to think "crashing code is
unreliable". But really, crashing is quite a safe and easy to reason about
behavior. But having to constantly program against any possible bug leads
to unmaintainable, brittle, impossible to reason about code. If every
index-expression, every pointer-dereference and every method call needs to
be wrapped in a conditional, it becomes impossible to really understand
where a failure is coming from and how a program behaves in different
failure modes.
The weird part, at least, why it might feel weird, is that you might never
> encounter the issue as a runtime panic, but as a compiler error, it will
> hit you every time. This will make exploring and experimenting with
> unfamiliar imports, features, and patterns more complicated, but it is the
> entire point, to my mind, of having a type-system.
>
> P.S. Bug in the snippet given by OP? I expected to see "x != nil" instead
> of "x == nil", or else change comments around.
>
>
> On Wednesday, March 23, 2022 at 4:15:13 PM UTC-5 axel.wa...@googlemail.com
> wrote:
>
>> Personally, I think this leads to very unreadable code, for no real
>> benefit.
>> If a nil-pointer dereference happens unexpectedly, that's always a bug. A
>> panic is the correct signal to tell me about that bug, so I can go ahead
>> and fix it. So, making my code less readable to get less robust code seems
>> like a lose-lose proposition to me.
>>
>> Of course, people can always choose to write/use whatever static checker
>> they want. I'm not opposed to this existing. I just don't think it should
>> be in the compiler or in `go vet`.
>>
>> On Wed, Mar 23, 2022 at 10:01 PM 'Michael Toy' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> I barely understand Go, so this is likely a stupid idea. Since Go uses
>>> nil for a lot of things, lots of things can be nil.
>>>
>>> I am not a huge fan of the null safe accessor. (
>>> https://github.com/golang/go/issues/42847 )
>>>
>>> I am a huge fan of the compiler telling me the places where I have not
>>> checked for nil ... It took me a while to get used to languages which do
>>> this, but now I can't imagine living without it.
>>>
>>> Is it crazy to wish for ...
>>>
>>> if x == nil {
>>> // this does not produce an error because x is known not to be nil
>>> x.interfaceFunc()
>>> }
>>> // this DOES produce an error/warning if y is possibly nil
>>> y.interfaceFunc()
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/5a700cd9-9274-4756-80a6-9d322232afebn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/5a700cd9-9274-4756-80a6-9d322232afebn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/14f6ade8-fe5b-4876-b692-ed98764eaa55n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/14f6ade8-fe5b-4876-b692-ed98764eaa55n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfHUW%3D7eKdxNhVE7TcdDLyp8TB3Xmc3BPCSfK-kc2B8wsw%40mail.gmail.com.
