proposal: Go 2: use an identifier other than nil for uninitialized interfaces

[pcostanza]

This is a variation of #21538 with a very important difference (see below). It's also related to #22729 and #24635.

It's confusing that nil can be used both as a value to represent an uninitialized interface, and as a value for the pointer that an interface is initialized with. This is a stumbling block for people new to Go, but also trips up experienced developers every now and then.

Proposal: use a value other than nil for uninitialized interfaces. To avoid adding new pre-defined identifiers, the value could be syntactically represented as {}, for example, but it may also be ok to introduce a new identifier, like null or nilinterface, or some such. This means testing for an uninitialized interface would have to be expressed like this:

var v interface{}
...
if v != {} {
   ...
}

With this proposal, tests against nil (like in v != nil) are not allowed anymore. This proposal explicitly does not suggest to add a way for testing for typed nil pointers stored in interfaces in any way. (If you prefer such a feature, refer to one of the other proposals mentioned above, or submit a separate, potentially complementary proposal.)

Rationale: A lot of people seem to be strongly opposed to adding a way to allow for testing for typed nil pointers being stored in an interface variable other than through the reflect package, and strongly encourage people to call methods instead that are supposed to handle nil pointers gracefully. I still strongly believe the language is improved if interface variables are simply not comparable to the nil identifier anymore at all to make that distinction even more explicit, and ensure that developers don't falsely believe they compared to any other possible meaning of nil.

This proposal implies a change that is not backwards compatible, but it should be easy to write a tool that automatically converts programs since a type checker should be able to detect the relevant cases.

[bcmills]

Could you clarify how this proposal differs from #22729?
It seems like pretty much a strict subset, albeit with nilinterface renamed to {}.

Note in particular point (5) of @ianlancetaylor's proposal:

5. If we are ever willing to make a backward incompatible change, we can make v == nil a compilation error rather than simply being a vet error.

[pcostanza]

Yes, it’s a strict subset. Considering that the other proposals all gained criticisms for aspects that go beyond this particular subset, I believe it’s better to propose a minimal version that focuses on the IMHO essential part.

[pcostanza]

Here is an attempt at showing that this proposal objectively improves the language.

Consider the following code fragment:

v = nil
w = v
if w == nil {
   fmt.Println("no")
} else {
   fmt.Println("yes")
}

Without the proposal above, this code fragment is ambiguous: You need to know the type of the variable w to determine whether this code fragment will print no or yes. If w is an interface type, it will print yes, if w is not an interface type (for example, some pointer type), it will print no.

With the proposal above, variables of interface types are not allowed to be compared to nil. Then you have two possible cases:

v = nil
w = v
if w == nil {
   fmt.Println("no")
} else {
   fmt.Println("yes")
}

Here, w must be a variable of a non-interface type, because only such a variable can be compared to nil, so the fragment will print no.

Alternatively:

v = nil
w = v
if w == {} {  // or null, or nilinterface, etc.
   fmt.Println("no")
} else {
   fmt.Println("yes")
}

Here, w must be a variable of an interface type, because only such a variable can be compared to {}, so the fragment will print yes. In both cases, there is no need for looking up the types of the variables involved to determine the outcome.

I'm not arguing that this particular example occurs often (it's artificial, so it probably doesn't). I'm also not arguing that it's hard to find out what the types of variables are (with a good IDE probably just hovering the mouse cursor over the variable name, without a good IDE scrolling to some other place in the code). I'm nevertheless arguing that this is nevertheless an improvement, and that in fact Go should have been designed like this from the beginning. I also believe that the change shouldn't cost much, because the compiler has to know about the different roles of nil already anyway, and it should also be trivial for a tool like go fix to make the necessary changes to existing source code. I believe the cost/benefit ratio is really good here. ;-)

[pcostanza]

#24635 is a related but completely different and orthogonal issue. #21538 combines the proposal discussed here and #24635 (which is unnecessary, because they address different issues, so it's good that #21538 was closed).

#22729 goes a lot further than the proposal discussed here. As with #21538, it combines solutions to related, but essentially different problems, IMHO.

[ianlancetaylor]

I can't say that I am sanguine about {}. People will have to write code like v = {} and F({}). Code like this becomes valid Go:

if a, b = F(), {}; a != b {}

We will see a great deal of code like

if err != {} {
    return fmt.Errorf("X failed: %v", err)
}

It doesn't correspond to anything else in the language. I think a predeclared identifier is more feasible, but as the discussion in #22729 shows picking that identifier is not straightforward.

Separately I note that even though Go 2 can break language compatibility, it must still be largely backward compatible. Requiring every line of the form

if err != nil {

to change would be quite drastic. I think it's infeasible without a transition plan.

[pcostanza]

This proposal is not about syntactic choices. It doesn't have to be {}, it can be null, or nilinterface, or empty, or something else.