[kjksf]

It's hardly a better solution.

In Go nil is a special identifier that represents a "zero value" for several types (pointers, interfaces, functions, slices, channels).

"unset" would be a "zero value" for interfaces so that nil could be "interface that has a type but whose value is an zero value of a pointer or function or slice or a channel.

This is inconsistent - now you have 2 identifiers to represent a concept of "zero value".

[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.

[eternalban]

> In Go nil is a special identifier that represents a "zero value" for several types

I think this is the crux of the problem. OP's confusion would be addressed by

    var foo someType = someType.nil
    var bar someInterface = foo
    if (bar == interface.nil) // prints false without confusion

[dilap]

yeah, you've exactly identified the confusion -- assigning the zero-value of a pointer to an interface does not give you the zero-value of the interface.

using the same word to represent these two things makes this more confusing, because it violates our intuitive sense of algebraic laws (a = nil, b = a => a == nil); using different words for the zero-value of interface and pointer would break this false intuition (a = nil, b = a =/> a == unset), and save a lot of confusion.