Ayan, imagine I am part of a development team. In our program I have a
pointer r:
r *myType
My variable r can be nil, because that is a valid situation. It is used in
dozens of places, like this:
if r != nil {
r.doSomething()
}
That is a very usual idiom, no only in Go, but in many languages. Every
programmer is acquainted to that.
Then, years later, other programmer in my team decides to create an
interface to better capture a new understanding of the problem at hand,
changing the type of r to:
r myInterface
Subtly, the meaning of
if r != nil {
r.doSomething()
}
changes. Under the right circumstances our software starts to behave
strangely. What?
This problem is dangerous because it is so subtle. We will read our old
code time and again to no avail, because everything seems fine and no one
has changed that "if r != nil r.doSomething" in ages.
As Dave Cheney said in
https://github.com/golang/go/issues/21538#issuecomment-323561094 that could
be solved:
"by making an nil interface and an interface which contains a type who's
value is nil also equal to nil."
On Wednesday, November 1, 2017 at 7:06:31 AM UTC-2, Ayan George wrote:
>
> On 10/31/2017 12:42 PM, oju...@gmail.com <javascript:> wrote:
> > Today you can't, Ayan.
> >
>
> Right -- I understand that. I'm asking how would you propose Go do
> that? What changes would you make to fix this?
>
> I'm asking: If you claim Go is fundamentally broken in this way, how
> would you fix it?
>
> -ayan
>
>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
