[Someone]

But they are different.

go has _three_ different concepts: what is now called nil has instances from two classes, let's call them nil.type and nil.interface.

Discussion is about whether it would be better to require programmers to explicitly specify the .type or .interface part in the code they write, or to let the compiler infer it from its arguments (with the special case that it should assume that, in nil == nil, both have the same meaning, so that it evaluates to true)

I think I would favor having two separate names in my source code, with the caveat that the compiler should make it illegal to write x == nil.interface if x is a type and vice versa, but I know too little about go to claim that's really a good idea, and also think it would change if go got generics (and maybe, the code generation thing it has now in place of generics (go generate) already would change my opinion, if I took time to think it over)

[eternalban]

I should scroll before I post!

We're in agreement but I think <type>.<value> is a somewhat universal syntactic construct.