> Here, both x and y are conceptually nil, but y cannot be compared to nil. I disagree with the "conceptual nilness" of y. x is a perfectly fine and usable imp

> Here, both x and y are conceptually nil, but y cannot be compared to nil. I disagree with the "conceptual nilness" of y. x is a perfectly fine and usable implementation of io.Closer. It doesn't even panic. Having a nil-check (i.e. "does this interfaces contain a value?") return true seems dishonest to me. I agree, that it was a bad choice to call both the zero-value of pointers and the zero-value of interfaces "nil". But in general, the possibility of nil-pointers being valid values and implementers of interfaces is useful. For example if you have a linked list or graph-structure. I also asked about it on reddit and got this answer: https://www.reddit.com/r/golang/comments/6sktsr/typed_nils_in_go_2/dldjtfi/ https://www.reddit.com/r/golang/comments/6sktsr/typed_nils_i...