Comment by rdtsc | Hacker News Reader

Comment by rdtsc | Hacker News Reader

Parent Full thread

> also, can someone please explain the issues around 'nil' ? i fail to appreciate author's concern about those..

The question can be thought of as two parts:

1) Whether nil should be a base value for objects. If something points to type t, should that be allowed to be nil. It is obvious that it should if coming from C/C++/Python, not so obvious if coming from Haskell for example.

2) Should the lack of objects, or should error conditions be represented by nil. Say lack of a an object in a map is indicated by returning nil. Should it throw an an exception instead? Now, go doesn't have exceptions so it needs something like this perhaps. Or maybe panic should happen.

To expand on 1). If you are coming from Haskell (or any strong typed language) the thinking is, you are already paying the price for static checking, strong types, compilation step etc. It would be nice to have explicit non-nil types. You can say this function accepts a reference to this object and this cannot be nil. During compile time the typechecker/compiler will do a more rigorous analysis based on that, and barf out an error then instead of during production.

Like in Haskell you can explicitly say something may be nil (Nothing):

       data Maybe a = Nothing | Just a

I don't personally lean one way or another here. I just don't have a strong opinion either way. I understand the trade-off. But this is how I interpret what the author means by his issue with 'nil'. Hopefully this helps.

Golang maps do not return nil for missing values of maps. Referencing a missing value in map returns the zero value for the value type, which for int is 0, for string is the empty string "", bools are false, and so forth. Golang also has the two-return-value form of map reference:

  value, exists = myMap[42]

For 1), modern C++ style generally frowns upon NULL pointers, preferring to use references, which are guaranteed to be non-NULL.

There is no such guarantee, a NULL reference can be created although it does require a little more effort than creating a null pointer.

However, null is just a special case of "invalid" pointer (e.g. point to freed memory), and it's very easy to create an invalid reference, e.g. take a reference into a vector and then push a pile more elements onto it, causing the vector to reallocate and move in memory, invalidating the reference.

You're talking about undefined behavior. There's no such thing as a null reference according to the C++ language specification.

So? It's still possible to create one. (There's no such thing as dereferencing an invalid pointer according to the standard, but that still happens.)

If it takes undefined behavior to create a "null reference" then by definition it's not possible to create one and still have a well-defined program. That is, you have bigger problems than "null references" to worry about.

There is no such guarantee. I fixed more than one bug of invalid references.

My understanding is that it is impossible to have a NULL reference. Can you show us some code that ends up with a NULL reference? I'd be curious to see how that can be done!

Dereference a NULL pointer and use the result to initialize a reference. Sure, it's undefined behavior, but so are all the problems that result from NULL pointers, and in practice it doesn't crash until you "dereference" the reference by looking at the value, so it's probably as hard to track down as a NULL pointer crash.

I'll leave it as an excercise to you. Promise me that I don't have to maintain your C++ code until you completed it.

> Hopefully this helps.

yes, it does. thank you for your kind explanation.

Reply on news.ycombinator.com