gt; 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_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...@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_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/4bf6c7d8-3970-4065-b0b6-62a8430ddc8bn%40googlegroups.com.
