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/2eee7c5c-6014-4fa8-a967-73676f0ed2c8n%40googlegroups.com.
