Nil in Go is typed in theory and sort of untyped in practice

https://utcc.utoronto.ca/~cks/space/blog/programming/GoNilIsTypedSortOf

by goranmoomin • 5 years ago

127 68 5 years ago

utcc.utoronto.ca

temac• 5 years ago

I'm not sure why it would be significantly better to have reliably "typed nil" over "untyped nil". The concept has no real definition to begin with: what matters about sound typing are the static guarantees a type brings, or by association even if this not really the same concept, the "dynamic guarantees" about the behavior of objets of some "dynamic type" (that is the variable used as a handle to the objet had no guarenteed static type, but in most cases the object themselves have a type). Acting on a "type" of nil values seems to make very little sense. Maybe there are obscur constructs where this would be handy, but at the first glance I would consider it probably indicative of a dirty hack, and recommend looking for alternate solutions.

stcredzero3• 5 years ago

In Smalltalk, nil was a constant that contained the only instance of the class UndefinedObject.

What some people did, was to put methods on UndefinedObject to implement a "NullObject" pattern for their domain objects. Since everything is default initialized to nil, everything would just work.

The big downside of this, were beginners putting methods on UndefinedObject that they should not have. There's a thin line of conceptual understanding between a bit-bucket that hides errors from you, and a useful NullObject. Some people would call this a "dirty hack" for that reason.

curryst2• 5 years ago

It's probably not useful in Go's type system. It would be useful if there were union types, though. I sometimes end up using pointers for nullable fields because the zero values are significant in whatever domain I'm working in. I either have to make it a pointer, or I have to implement a new special zero value, or I have to make a struct that can keep track of whether a value has been set or not.

It'd be nice to be able to do

    type MyStruct struct {
      ID int || nil
    }

And have the compiler understand that the ID has to be either an int or nil, and to give me errors if I try to use it as an int without making sure it isn't nil.

kazinator3• 5 years ago

I'm afraid this rings slightly hollow for me.

We can likewise claim about C that "0 in C is typed in theory and sort of untyped in practice" because constant expressions of integer type that evaluate to 0 can serve as null pointers of any type:

   char *p = 0;        // no cast required
   if (p == 0) ...     // no cast required
   time_t t = time(0); // fine
   char *q = 1;        // error; requires (char *) 1.

We can't think of this 0 as an object; it's just a source code token that provides a null pointer of the right type, which is statically obvious from the use.

The only time it's a problem is in unsafe interfaces:

   int old_style_string_fun();
   int variadic_fun(char *first, ...);

   old_style_string_fun(0);
   variadic_fun("first", 0);

Here, the wrong type is inferred; the 0 just behaves like the ordinary constant of type int. A null pointer to char was intended, which requires (char *) 0 must be used.

None of this challenges the fact that we can have a variable of type int, whose value is 0.

JeremyBanks• 5 years ago

C is an ~untyped language so this comparison isn't very helpful.

kazinator3• 5 years ago

Though a popular meme, it is false. C has an extensive static type system, requiring programs to be checked and diagnosed. This is quite helpful in catching bugs and refactoring and all that. That type system doesn't encode everything that some people would like, such as preventing a program from retaining and using a pointer to a datum that no longer exists. It allows implicit conversions that some people would like to be explicit (e.g. integer to floating-point and vice versa), but in those situations, the static type of every operand, and of the result, is known and the compiler chooses the conversion accordingly.

neild• 5 years ago

The predeclared identifier nil is a constant, like 0 or "".

Like 0 or "", nil is untyped. Go has both typed and untyped constants. 0 also is untyped, which is why you can write x==0 regardless of whether x is an int32 or an int64.

Unlike 0 or "", nil does not have a default type. The default type of a constant is the type that it is implicitly converted to when a type is required. For example, "x := 0" declares a new value x with the value 0, but 0 is untyped. Untyped integer constants have a default type of int, so x is given the type int.

Since nil does not have a default type, it's an error to write "x := nil".

You can declare a typed constant with the value 0 or nil. int32(0) is a constant with type int32 and the value 0. (* int32)(nil) is a constant with the type pointer-to-int32 and the value nil.

Variables of an interface type can hold any value that satisfies the interface. For example, a value of type io.Reader can hold any value that has a Read method with the appropriate signature.

The common confusion about nil occurs because you can compare an interface value to a non-interface value.

  var b *bytes.Buffer       // b is a variable with type *bytes.Buffer
  var r io.Reader           // r is a variable with type io.Reader
  r = b                     // r now holds a value with type *bytes.Buffer and value nil
  b == nil                  // true: b is nil
  r == b                    // true: r and b are equal
  r == (io.Reader)(nil)     // false: r is not a nil io.Reader
  r == (*bytes.Buffer)(nil) // true: r contains a nil *bytes.Buffer
  r == nil                  // false: r is not a nil io.Reader

The confusing part is that last line. How can r not be nil, when it contains a nil value? And the reason is hopefully apparent from the previous two lines: It depends on the type of "nil".

Whether you find this a wart in the language or not, this is not a case of nil being either typed in theory or untyped in practice. The predeclared identifier "nil" is an untyped constant.

mh-• 5 years ago

exceptionally clear explanation, thank you.

morelisp4• 5 years ago

Like 0 or "", nil is untyped. Go has both typed and untyped constants... Unlike 0 or "", nil does not have a default type.

So it feels like you're trying to draw some distinction here that is like, "look, nil isn't really that special - there's groups A and B, and the core confusion is people think nil is in group A while the truth is in it's group B." And it's true, Go has both typed and untyped constants.

But as far as I know, nil is the only untyped constant without default type. So "group B" is still just nil, and nil remains a sui generis source of confusion in Go.

134154• 5 years ago

Yes, but giving nil a default type would be way more confusing.

stcredzero3• 5 years ago

0 also is untyped, which is why you can write x==0 regardless of whether x is an int32 or an int64...

Since nil does not have a default type, it's an error to write "x := nil".

But not an error to write "x := 0"?

saghm• 5 years ago

The next paragraph they wrote explains this: "Unlike 0 or "", nil does not have a default type. The default type of a constant is the type that it is implicitly converted to when a type is required. For example, "x := 0" declares a new value x with the value 0, but 0 is untyped. Untyped integer constants have a default type of int, so x is given the type int."

dhagz• 5 years ago

Because 0 has a "default type" of int. So when the compiler goes to determine the type of x, it sees its set to 0, which the compiler assumes to be an int.

I've found thinking about nil too much in Go hurts or creates weird loops in my brain, so I just tend to worry about it when I'm dealing with interfaces or pointers. Everything else I'm looking at zero-values.

masklinn2• 5 years ago

No, because as they note constants can have a default type[0]. For integer constants, that's `int`. Meaning if a literal integer constant is not otherwise typed, it will default to `int`.

[0] https://blog.golang.org/constants#TOC_5.

siebenmann2• 5 years ago

The Go specification is careful to not call 'nil' a constant, and in fact at one point specifically says that it isn't ("Conversions", in the section on converting constants into typed constants, which actually uses '(*int)(nil)' as an example of something that is not a typed constant). Also, although it wasn't clear in the entry, the original article that it was a reaction to talked specifically about 'nil variables' (ie, variables with the value of nil).

(Even the concept of 'the value of nil' is tricky in Go; I believe the specification only talks about things being comparable to nil or allowing nil to be assigned to them. The specification really goes to a lot of work to not treat nil as a value, exactly. I suspect that the Go spec authors really did not want a rerun of the C idea that the NULL pointer is '0' and has an all-zero value and so on.)

(I'm the author of the linked-to entry.)

yoneda• 5 years ago

Huh, so equality isn't transitive in Go. Yikes.

Spivak• 5 years ago

Eh, languages end up with this all the time with type conversions.

In JS:

    false == undefined => false
    false == null => false
    undefined == null => true

adonovan• 5 years ago

In many languages, equality is often intransitive when you consider implicit conversions. For example:

   type T int

   const a = 0
   var b T = a
   var c interface{} = b
   fmt.Println(a == b, b == c, c == a) // true true false

https://play.golang.org/p/YZ-0Ym5lJ7R

esrauch3• 5 years ago

r==b and b==nil but r!=nil seems like the kind of thing that people give JS a lot of crap over.

mirekrusin5• 5 years ago

Can you please give more concrete example that is valid js but is absurd logically?

drvd• 5 years ago

How can r not be nil, when it contains a nil value?

In the same way a slice can contain one or more nil values without itself _being_ nil. A gift box containing nothing is not itself nothing.

And the reason is hopefully apparent from the previous two lines: It depends on the type of "nil".It depends on the type of "nil".

Well, no. "r == nil" tests whether r itself is nil (i.e. the zero value of that interface type) which it is not. It contains b and is thus no longer nil. The type doesn't play a (large) role here. This misconception might be due to the fact that lots of types can be nil: slices, maps, channels, functions and (unfortunately) interfaces.

Nobody is astonished that a slice containing any sort of nils is not nil itself; that a buffered channel containing nils is not nil itself and that the constant function `func()*int { return nil }` is not nil itself either. Only for interfaces this poses a problem. If interfaces wouldn't be "nil" but lets say "zilch" than it would be evident that r != zilch.

miga• 5 years ago

It is very confusing that equality in JavaScript is not transitive: https://imgur.com/5pFXFbR.

Apparently equality in Go is no longer transitive either...

jerf5• 5 years ago

I think I'd need to see an example of that to be sure. What's talked about here doesn't really lead to that, because in these examples, values are getting passed through a function call boundary.

There's a lot of rules in Go for what == does, and maybe there's something non-transitive in there, but I'd definitely need to see someone prove it on https://play.golang.org/ to be sure. Offhand I can't think of how to make one.

morelisp4• 5 years ago

There is a nontransitive example heading this very comment section:

    var b *bytes.Buffer
    var r io.Reader = b
    fmt.Printf("r == nil: %v; b == nil: %v; r == b: %v\n", r == nil, b == nil, r == b)

    r == nil: false; b == nil: true; r == b: true

nicoburns• 5 years ago

JavaScript is fine so long as you stick to === rather than ==. At work, == is completely banned and tjis is enforces by CI.

aikah• 5 years ago

It is very confusing that equality in JavaScript is not transitive: https://imgur.com/5pFXFbR.

There are 2 types of equality in JS, shallow (==) and 'strict' (===). It's fine because JS is a dynamic, weakly typed language.

Go isn't supposed to be.

macintux• 5 years ago

Much discussion about nil in Go just yesterday:

https://news.ycombinator.com/item?id=26635529

jerf5• 5 years ago

For some context, I've been programming in Go for about six years now, and I've literally never even thought about this.

In general, you really haven't got much reason to be worried about something's "interface type", because if you're really worried about something's "type" (which can happen) you are almost certainly worried about it's "concrete type". The only interesting thing you can ask about the interface type directly would be "Does the value inside this interface implement this interface?", and the answer is statically yes, the compiler assured that, and the interface type is statically assured at runtime, so it's not a very interesting question. Even if fmt added a way to "see" the interface type passed in, I can't imagine what it would be useful for, because it could only ever be:

     var x SomeInterfaceType

     // some number of lines of code

     fmt.Printf("%I\n", x)

which would statically print "SomeInterfaceType".

So, I mean, it's not like anything said in that blog post is false necessarily, but if you're collecting reasons to hate on Go's nil handling, there's no real justification in adding this to your list. I'd also add that I answer newbie questions a lot on Reddit, and nothing even remotely like this has ever come up there, either.

autarch• 5 years ago

I agree that you won't think about this too often. However, if you're trying to use the reflect package to get type information about variables, you may end up having to think about it (and like me, you may end up feeling very confused!).

eptcyka2• 5 years ago

I programmed in Go for three years, and got bitten by this at least twice.

Being able to determine if a value that implements an interface is nil or not would really be nice.

waheoo• 5 years ago

How does nil implement an interface?

jerf5• 5 years ago

That's actually not what this blog post was talking about. That's a separate issue. My commentary can be found https://news.ycombinator.com/item?id=26636227 , and see the grandchild as well.

ivanech• 5 years ago

This reminds me of Rich Hickey's "Maybe Not" talk

tapirl• 5 years ago

'nil' in Go is just an identifier to represent the zero values of some kinds of type. A bare nil is always untyped and it is the only untyped value which has not a default type.

Zero values behave the same as non-zero values in many aspects.

More read: nils in Go https://go101.org/article/nil.html

The facts that several kinds of type share the same zero value literal representation really confuse many new gophers, but this is hardly a problem when you get familiar with the design.

There are proposals to remove the new-gopher confusion.

* https://github.com/golang/go/issues/22729 use different zero identifiers for different kinds of type

* I remembered that there is a propsoal which propose using `null` for non-interface zero values but still using `nil` for interfaces. I couldn't find this issue now.

Nil in Go is typed in theory and sort of untyped in practice

Related Stories