Add comparison of null/nil safety and syntax

[roryokane]

I researched these features because I was wondering if either language had a solution like Rust’s Option. Neither language does.

I decided the comparison result was “?” because D is better by default because more of its built-in types are non-nullable, but Nim can be made safer than D if you put in the work of redefining everything using the experimental not nil type annotation.

[roryokane]

By the way, regarding this part of my description of Nim’s null handling:

The notnil feature was made experimental in 2018, but in 2020 its brief documentation is still in the wrong section of the manual

I plan to make a PR for Nim to move the not nil documentation to the correct section of the manual. I will update this PR if and when that Nim PR is merged.

In that potential future update to this PR, I will update the link to not nil’s documentation. But I won’t remove all mentions of the docs being in the wrong section of the manual – it having been that way for years is still good evidence that not much attention is paid to this feature.

[timotheecour]

thanks for the PR! just click resolve on each comment when you've addressed it (easier to track each independently)

[timotheecour]

ping @roryokane

also see this:
https://irclogs.nim-lang.org/06-04-2020.html#13:52:31

Araq | isNil could be deprecated, it's pointless

which echos what I was thinking as well, now that seq/string can't be nil

[timotheecour]

Only ptr and ref types (and cstrings) can be nil

actually, also pointer, but... can be fixed, later.

super thanks! merging!