It is good practice for a function to validate the values it receives from
outside, whether they are function arguments or return values from other
functions. It is not just a nil check, but a proper validation. I don't
think that automated nil check can replace proper validation.
Sometimes for things that shouldn't happen, it is often more practical to
just let it crash and burn. Often the problem is not with the function
itself, but somewhere higher up the hierarchy. By letting it fail
spectacularly, it is easier to identify the bug.
On Friday, March 25, 2022 at 8:36:30 AM UTC+7 Ian Lance Taylor wrote:
> On Thu, Mar 24, 2022 at 3:23 AM Brian Candler <b.ca...@pobox.com> 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.
>
> Some proposals in this space:
>
> https://go.dev/issue/30177
> https://go.dev/issue/33078
> https://go.dev/issue/42847
> https://go.dev/issue/49202
>
> Ian
>
--
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/e8b81796-fca2-4007-b57d-d8daf70f5547n%40googlegroups.com.
