The discussion is quite informative for me to read, thanks for responding.
Go uses nil in a way which I don't quite yet grok, and so I had no idea if
it was even a reasonable thing to wish for. Today I am writing in
Typescript, and the way null is integrated into the type system now (after
a while) feels natural and helpful to me.
Sam is correct, there is bug in my Go snippet in the post. For humor value
only, I would like to point out that the imaginary Go compiler I was
wishing for would have found that bug!
I think Brian gets to the heart of my question, which is "If I really
understood Go, would I want something like this". I am hearing, "No, you
would not"
I think if I were to have a long conversation with Axel about "what is it
that makes programs robust and maintainable" we'd go round in circles a
bit, as should happen any time you talk about something complex and
important. I think I disagree with some statements, but even the
disagreement is super helpful.
Thanks for the discussion!
-Michael Toy
On Thursday, March 24, 2022 at 12:22:44 AM UTC-10 Brian Candler wrote:
> The OP hasn't said specifically which language or feature they're
> comparing with, but I wonder if they're asking for a pointer type which is
> never allowed to be nil, enforced at compile time. If so, a normal
> pointer-which-may-be-nil would have to be represented as a Maybe[*T] or
> union { *T | nil }. To use such a pointer value at runtime you'd have to
> deconstruct it via a case statement or similar, with separate branches for
> where the value is nil or not-nil. I am sure there have been proposals
> along those lines floated here before.
>
> I don't think this would negatively affect code readability, because a
> function which takes *T as an argument can be sure that the value passed in
> can never be nil (the compiler would not allow a value of type Maybe[*T] to
> be passed). Conversely, a function which accepts Maybe[*T] as an argument
> is explicitly saying that the value passed may legitimately be nil, and
> hence it needs to check for this.
>
> I like this idea in principle, but in the context of Go it would mean that
> *T does not have any valid zero value, so you would not be able to use it
> in any variable or struct which is not explicitly initialized. This would
> definitely not be Go any more.
>
> type T ....
> var t T // ok
>
> var p1 Maybe[*T] // ok
> var p2 *T = &t // ok
> var p3 *T // fails to compile (no zero value is available)
>
> type A struct {
> a Maybe[*T]
> }
> var q1 A // ok
>
> type B struct {
> b *T
> }
> var q2 B = B{b: &t} // ok
> var q3 B // fails to compile (cannot create zero-valued instance of this
> struct, because it includes a member which cannot have a zero value)
>
> On Thursday, 24 March 2022 at 09:41:23 UTC axel.wa...@googlemail.com
> wrote:
>
>> 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....@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...@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/4bf6c7d8-3970-4065-b0b6-62a8430ddc8bn%40googlegroups.com.
