I generally agree with your sentiment, it’s just the solution is where we differ. I think there are many non-language based approaches that are more flexible and probably more efficient. I find non-nullables get in my way.
If you can’t write a contract for your functions, you will never be able to modify your software with confidence.
If the design cannot prevent nulls, then yes, unfortunately, you are responsible for the proper handling of them. If you start adding !! to your code and get NullPointerExceptions, it was your own choice. You have to decide if and when null is allowed. If you can prevent nulls as soon as possible, things get a lot easier. If you know if null is not allowed only deep down the call hierarchy, then you have to think about what to do when you get a null but cannot handle it.
2 Likes
I can and do check contracts for functions and everything else, just not STATICALLY or not within the scope of that function or object. Also contracts do not just involve nulls but also other invalid situations. So if I have to do checks anyway, handling nulls separately is a pain and if they’re not static checks, then it’s not even possible.
That was the point of my long and boring post.
in 6 words : “nullable types are a killing feature” (present in most of modern languages (when null is not prohibited))
Sorry, I think you have to provide some code for me to understand what the actual problem is.
Let’s see what the inventor of null references thinks about them:
null reference != null type
either you use null reference + null null type (which is quite safe) or you remove null reference and use a type for this (rust…).
I agree with @jstuyts, You need to provide an example, before anyone can understand you. Any language has some type of object that means absence of something. At least they have union types with nothing. In kotlin you have non-nullable type and nullable type, which means object-of-that-type-or-nothing. Nulls are also used for proper interop with java, but forget about that, you are talking about language, not its specific application. The comment from @nutjob2 about the fact that you can’t get a runtime type from null is the only valid point in the whole discussion (I still did not get an example, where it is needed), but you should not access type information in runtime at all if you want to keep mathematically strict approach. Haskell does not have runtime types at all, and CS guys are head over the heels in love with it.
1 Like