[laumars]

Checking the value of a property [edit: return of method] after you've nil'ed the parent object is enough raise an exception in most languages. So yes I'd say that's an edge case. Where Go gets it wrong here is because nil isn't really `nil` you get a silent `false` rather than an obvious crash + stack trace. But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.

[masklinn]

You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. This issue can occur for any function which takes an interface-typed parameter. That's usually how it happens: somebody passes in a `nil` which comes from a pointer-typed variable: https://play.golang.org/p/ADTvLDDrw6

> But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.

No, it would not. In Java, null is null whether it's typed as a concrete reference, as an array or as an interface.

[laumars]

> You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil.

Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the language. So Let's break the code down: first they create a struct exposed via an interface{}

    type T struct{}

    func (t T) F() {}

    type P interface {
        F()
    }

func newT() *T { return new(T) }

Then they create an initialized variable that object type:

    t := newT()
    t2 := t

...and set that interface{} to nil:

    if !ENABLE_FEATURE {
            t2 = nil
    }

Then they check the value returned from a method of the struct - bare in mind this is after the struct has been `nil`ed:

    thing := factory(t2)
    fmt.Println(thing.P == nil) // returns nil

If there's a likelihood that they could be working with nil interfaces then they should be first checking the value of the interface before checking the value of the methods within it. Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. So I'm not defending Go's behavior but their example is peculiar to say the least.

That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.

[coldtea]

>Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.

Most OO languages wont report an interface as non null if its value is null. Go will.

[laumars]

Indeed - I wasn't defending Go's behavior here. I was just replying to your question about whether it is an edge case or not. Since the code would be broken in any OOP language I do consider this to be an edge case. But that doesn't mean I like nor would defend Go's nil type system.

[masklinn]

> Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article.

Not really, Go supports (and encourages properly handling) nil method receivers.

> Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.

Setting aside the fact that this is not quite true[0], there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state and possibly but not necessarily faulting at some other point later on. PHP gets regularly and deservedly panned for the latter.

[0] nil is a message-sink in obj-c (any message can be sent to nil and will be a no-op returning nil), and you can make Ruby or Smalltalk behave that way (or any other) as their nil is a regular object with a normal type which you can go and extend

[laumars]

> there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state

Of course. But then I also made that point too. Frequently in fact and in the very post you're replying to as well. Plus also in the other reply that echoed the same point you're raising here. I'm not justifying Go's behavior here. Absolutely not! It is unexpected and bad. But we have already established and agreed on that point so moved onto another question regarding whether the authors example is an issue that is likely to arise often. I was attempting to explain why I felt it was a poor example and not trying to justify Go's behavior - which at risk of repeating myself: we all already agree is bad.

[coldtea]

>Checking the value of a property after you've nil'ed the parent object is enough raise an exception in most languages.

Only you're not doing that here. If anything, it's the inverse.

>But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.

In other languages the interface can be null as a value even if the interface has a not-null type.