At the end of the day, you can't get away from the fact that arguments and return values may be NULL or they may not, and if so, NULL is interpreted in a certai

At the end of the day, you can't get away from the fact that arguments and return values may be NULL or they may not, and if so, NULL is interpreted in a certain way by the program that depends on the context. Whether these semantics are documented, enforced by the language, or neither, the programmer using a function must know them in order to write correct code. The convention I've worked with is that these semantics are either obvious (because the scope of a function is small, and it's reasonable to require programmers to examine the function to see what it does) or documented. Mandating that the basic types cannot be null and requiring a special null-able type forces programmers to consider this issue, but if you work with a code base that understands the above, I'm not sure the trouble and obfuscation is worth it. There's a history of elevating useful programming patterns (constructors, generic references, and dozens of other C++ features come to mind) to the level of being enforced by the language or runtime, and in most of these cases I've found the cost of doing so (in language complexity and inflexibility) far outweighs the benefit of preventing programming mistakes.