[aatd86]

Very interesting work. I wonder what were the difficulties encountered. Aliasing? Variable reassignment wrt short declaration shadowing?

Hopefully with time, when exploring union types and perhaps a limited form of generalized subtyping (currently it's only interface types) we'll be able to deal with nil for good.

Nil is useful, as long as correctly reined in.

[mrkeen]

> Nil is useful, as long as correctly reined in.

A good way to rein in behaviour is with types. If you need Nil in your domain, great! Give it type 'Nil'.

[aatd86]

Yes that's part of it. It will probably require a nil type which is currently untyped nil when found in interfaces.

The untyped nil type is just not a first-class citizen nowadays.

But with type sets, we could probably have ways to track nillables at the type system level through type assertions.

And where nillables are required such as map values it would be feasible to create some from non nillables then ( interface{T | nil})

But that's way ahead still.

[candiddevmike]

It's really easy to check a field of a pointer struct without first checking the struct is non nil. Would be interesting if go vet or test checked this somehow.