I'm not sure if this topic has been discussed before, but since i found nothing on it, i want to know your opinions on this 'approach'.
Usually, when advertising ufcs it is talked about how flexible code can be written. But, from the perspective of the default oop programmer, it has a great advantage: you can elude null pointers.
Consider the following java snippet: http://pastebin.com/8WF4gPaq
We are used to constantly checking against nulls. There is no easy work around. Most languages forces non-null declaration by default, which doesn't solve the main problem. Most of the time null is desirable as an 'empty' object, we just want to get ride of the exceptions.
Now, with Nim, seems to me like the problem is mostly solved for ref types: http://pastebin.com/nMu6mzfF You can work with nils, not fight against them. You can turn nil to work as a secure and fast null object and completely forget nulls.
As i said, i dont know if this is a well-known property or what its disadvantages are. But, in case i'm right, shouldn't this 'practice' be encouraged in tutorials? It can serve for marketing purposes too: "say goodbye to nulls with Nim".
Disadvantage is you can't dispatch methods on nils. Other than that I also find this possibility a great advantage, but I would not say It should be used everywhere. E.g. it might be useful for ref types with container semantics (add item to nil container would create). But not for a window type. Adding a view to uncreated window hardly makes any sense.
So to summarise, in any case the user of your code will have to know whether your proc accepts nil or not, and no assumptions can be made on that =)
This isn't really the big problem with null pointers. The issue with null pointers is that unexpected null pointer errors arise primarily from having variables or object/record fields that have not been initialized. This then results in an error when the null pointer is actually dereferenced.
Being able to make null pointers a special case can then result in simply making the location of the final error seemingly even more unrelated to the place where the original variable/field was not initialized because it can be used for longer without triggering an error.
That nil can be used to represent a special value in a memory-efficient fashion is a separate feature.
It can serve for marketing purposes too: "say goodbye to nulls with Nim".
You haven't said goodbye to them, you're just checking for them in strategic places in a very limited example. This does not compare at all favorably to the way languages like Rust and Ceylon have completely eliminated null pointer exceptions from the programming model, and such "marketing" would not be received well.