proposal: Go 2: Ban typed nil interfaces through banning nil method receivers

[JavierZunzunegui]

Overview

Methods with pointer receivers have no restrictions on nil receivers. For example the below is valid:

type X struct{}
func (x *X) A() {...}
var x *X
x.A()

This extends to interfaces, creating the issue of typed nil interfaces. See typed-nils-in-go-2 for further context. I would like to see this situation removed in Go2 as typed nil interfaces are a source of bugs and offer no meaningful additional functionality.

Proposed Changes

I propose some changes to the Go2 language spec that would mean banning nil receivers, resulting in banning typed nil interfaces.

Make every method with a pointer receiver nil-pointer panic (at the beginning of the method) on a nil receiver. Implicitly that means if this == nil {panic NilPointer} is added at the beginning of every method. Note this is already implicitly added to most methods (those that use the receiver), just further down the method on the first use the receiver. Compared to the current specs, this would result in:

type X struct{}
func (x *X) A() {...}
var x *X
x.A() // this would now nil-panic (before any logic from A is executed)

Follow this up with another change, when assigning a (typed) pointer to an interface, check its value. If nil, set the interface value as the untyped nil. Note this means the specific type of the pointer unrecoverable. As an example:

type X struct{}
var x *X
i interface{}
i = x
isNil := i == nil  // currently isNil == false, I propose isNil == true
_, ok := i.(*X) // currently ok == true, I propose ok == false

This means if an interface is a typed pointer, it doesn't have to check if the pointer is nil or not, it is non-nil by design, hence the typed nil interface problem is gone.

Other considerations

I imagine others gophers will identify many others issues, these are some I am aware and would like to share upfront:

Optional nil receivers

Methods optionally allowing nil receivers are no longer allowed:

func (x *X) ... {
  if x == nil {
    return nil
  }
  // do something else

Instead a pointer type would be required, type XPtr struct {*X}, which would do the nil check.

Type assertions in nil types

By design, type assertions from nil pointer types are no longer supported. I don't think it is a common (or advisable) pattern, but it will still break the existing libraries using it. Where genuinely needed a pointer type could be used to wrap the pointer: type XPtr struct {*X}.

Methods not using the receiver

Methods do not have to use the receiver. The current spec does not distinguish between the two ways these may be defined (with/without named receiver): func (x *X) ... or func (*X) .... I suggest using this ambiguity and defining them differently in Go2, while the named receiver is just a normal method (and can't be called on a nil typed pointer) the unnamed one may be called on typed nil and does not have the implicit nil check. Note however that because interfaces are never typed nils, once called from an interface it will always be called with a non-nil receiver.

Methods as functions

Consider the below situation:

type X struct {}
func (x *X) A() {...}
var x *X
f := x.A // what to do with this? I suggest panic here

A method on a nil typed pointer is being assigned to a function variable. Calling that function will always panic, making it useless. For this reason I think it is better to change the language spec to have this panic on the assignment.

Compiler considerations

Note these considerations are not affecting the language spec, but I think they may make this changes more appealing.

This proposal means interfaces holding pointers do not have to check if the pointer they hold is nil valued. But that is largely useless if the first thing all methods do is check if the value of the pointer is nil. It would be much better if the nil check where performed by the caller (and still NilPointer panic if nil), improving performance by reducing the number of nil checks (among other things, methods would not need to make that check when calling other methods on themselves).

Also related, when assigning a pointer to an interface the value has to be checked for nil (which is not required currently). While this makes assigning to an interface more expensive, it is likely the compiler can optimize away many of these checks as the nil-ness of the pointer may be known at compile time.

[deanveloper]

And what about this?
https://play.golang.org/p/d8_dxaLJBRn

Are we really going to allow the assignment operator to panic, or is it just going to be disallowed to assign like this? Would this mean that go vet will flag every time I don't nil-check before I pass a pointer value into a function that takes an interface argument?

Especially with functions like fmt.Println which take interface{} arguments, does this mean I can't pass any typed nils in to them, instead it'd panic?

EDIT
Reading into this further, it looks like this is purely about banning nil method receivers, not removing typed nils entirely. I thought the goal was to ban typed nil values entirely, and that you were really only talking about nil method receivers as an example...

[deanveloper]

I don't like this mainly because I like thinking of methods in Go as syntactic sugar over functions, which really is what they are. A method really should just be a function, which allows arguments to be nil.

Something else that may become an issue is the following playground:
https://play.golang.org/p/mF44g_INnxP

[JavierZunzunegui]

@deanveloper the example in your playground is interesting.
I imagine (*X).DoSomethingshares the implementation with (x *X) DoSomething(i int), meaning it would have to enforce panic on nil, yes.
It is still just a function, it simply starts with check and panic on the first argument if nil.

[Merovius]

You are exclusively talking about pointers. But there are more types that can be assigned (and compared to) nil, namely funcs, chans, []s and maps. One implication of this, for example, would be that a nil sort.Ints no longer would be a valid sort.Interface.

In the end, I don't even think this proposal really helps or reduces complexity. Say, I have a function

type Barer interface {
    Bar()
}

type ConcreteBarer int

func (b *ConcreteBarer) Bar() {
    // …
}

func Foo(x Barer) {
    x.Bar()
}

Under your proposal, to make this correct we'd have to either

1. Add a nil-check to Foo against x
2. Or add a nil-check to every caller of Foo using a *ConcreteBarer

Whereas to make it correct now, you'd have to

3. Add a nil-check to (*ConcreteBarer).Bar

In the end, you'll still have to have nil-checks everywhere. You either have to have them in the receiver, or you have them in the caller, or you have them in the callee. At least right now, if *ConcreteBarer can work with a nil-pointer, you can leave out the nil-check.

Personally, I find the current contract pretty clear: If I take an interface, I expect that to be a valid value implementing that. I don't care what that value is and I don't want to. The implementer of the interface knows best what values are valid. Ultimately, if a message call panics, that just means the implementation wasn't valid (and note that it will always be possible for methods to panic, so you can't ever include that). With this change, the contract becomes much harder, because it isn't clear whether I have to check that it's a valid interface-value (i.e. not nil) or the caller has to check that it's a valid value of the type implementing the interface (which might be nil, if that's a pointer).

[JavierZunzunegui]

@Merovius thank you for the feedback. Like you said I hadn't considered other nulable types, but the same changes do apply to them. In fact it is easier for these than for pointers as none of these types (func, chan, [] and map) actually implement any interface (besides interface{}). Your sort.Ints example is flawed solved easily as []int doesn't implement sort.Interface, it is sort.IntSlice (defined as type IntSlice []int with Len, Less and Swap methods that implements it. Modify sort.IntSlice to be type IntSlice struct {data []int}, then it is not nulable, the fact that it contains a nil []int is irrelevant (it is just a parameter of a struct!). My proposal changes nothing (subject to this library change) on this example, it works identically in both cases.

As your feedback has highlighted, type definitions are also nilable and will be cast to untyped nil when used in an interface. The better patter is a struct wrapping the nilable: type NilablePtr struct {Nilable}

To emphasize, typed nil pointers do implement interfaces, which makes them more complex as defined in my original post. But these other nilable types don't implement (non-interface{}) interfaces, these proposed changes are irrelevant. The only change in these is that you can't recover the type of a nil:

var x func()
var i interface{}
i = x
_ = i.(func()) // this used to be OK, now panics as the nil has become untyped

But I don't think relying on this property significant (and if you are using it you should probably not anyways).

If not convinced just note the below code:

s := sort.Interface(sort.IntSlice(nil))
switch s.(type) {
  // case []int: // this doesn't even compile! "impossible type switch case: s (type sort.Interface) cannot have dynamic type []int (missing Len method)"
  case sort.IntSlice: // this case holds
}

[deanveloper]

Something to consider is that this would be pretty hard to implement in some kind of go1to2 transpiler... Although it is possible, so I don't think it should be a barrier to add a language feature, but it is something to think about.

Also, remember that nil maps and slices are significant and can be used. Consider the following:
https://play.golang.org/p/Pupjh2tZo_u

Sorry for any spelling mistakes, I'm on mobile right now

[Merovius]

sort.IntSlice is not nulable, the fact that it contains a nil []int is irrelevant (it is just a parameter of a struct!).

No, it is not. It is a defined type with underlying type []int and you can totally assign nil to it. sort.IntSlice(nil) is a valid implementation of sort.Interface. So you should talk about what sort.Sort(sort.IntSlice(nil)) does, if it should panic and if not, why not. Currently it works fine.

which makes them more complex as defined in my original post.

Not really, they are far less complex, TBQH. nil-maps allow reading-accesses without panic, which pointers don't. nil-slices allow range, slicing len and cap without problems - they are indeed pretty much identical to non-nil-slices, except that they compare true to nil. nil-channels allow sending, receiving and selects, with well-defined semantics (blocking forever).

ISTM that the rules for pointers are far simpler than for most of the other types - the only operation that is special about pointers is dereferencing and that works if and only if they are not nil. The other types allow more special operations that each have their own peculiar semantics when working on a nil-value.

But I don't think relying on this property significant (and if you are using it you should probably not anyways).

But as I pointed out - it is. Currently, code doesn't need to check for nil when passing well-behaved implementations as interfaces and code doesn't need to check for nil when being passed well-behaved implementations. Under your proposal, at least one (if not both) needs to happen.

i.e. pretty much all Go code out there is relying on this property, by not cluttering everything with nil-checks.

If not convinced just note the below code:

Type assertions on concrete types check whether the dynamic type is identical to the asserted one. []int an sort.IntSlice are different types - but that doesn't change the fact that sort.IntSlice has underlying type []int and thus is a slice-type that can be nil.

[JavierZunzunegui]

@Merovius regarding the Barer example, there is only one place that nil *ConcreteBarer has to be checked - when Barer is first assigned a *ConcreteBarer. Calling x.Bar() requires no nil check - x is already an interface. It's type has to be resolved to a *ConcreteBarer (as it already does without my proposal, of course), but once that happens it doesn't have to check if it is nil - it isn't by design, there are no more typed nil interfaces!

Not only there are no more nil checks, but they are almost certainly fewer. Say ConcreteBarer.Bar requires the receiver to be non-nil (for example by accessing some parameter on itself). Under the current go spec, it must nil-check the receiver before accessing it. With my proposal, again the pointer is non-nil by construction, and the check can be removed. Depending on your implementation and how many methods ConcreteBarer.Bar calls on itself it may even check for nilnes many times. With my proposal only once, and in fact a smart compiler might often remove that one also, after all (&ConcreteBarer{}).Bar() needs no nil receiver check!

The exception I do acknowledge is when ConcreteBarer.Bar doesn't access the receiver. When cast to an interface my proposal simply disallows it (by design), you need a non-nil pointer to access any functionality. In this case there would be once additional nil check, and one additional memory allocation. Or you can wrap it in a type ConcreteBarerPtr struct {*ConcreteBarer}, in which case you get the exact same functionality. See Methods not using the receiver in my original post for a little more details on this.