Null references redux

Michel Fortin michel.fortin at michelf.com
Sun Sep 27 05:33:03 PDT 2009


On 2009-09-27 07:38:59 -0400, Christopher Wright <dhasenan at gmail.com> said:

> I dislike these forced checks.
> 
> Let's say you're dealing with a compiler frontend. You have a semantic 
> node that just went through some semantic pass and is guaranteed, by 
> flow control and contracts, to have a certain property initialized that 
> was not initialized prior to that point.
> 
> The programmer knows the value isn't null. The compiler shouldn't force 
> checks. At most, it should have automated checks that disappear with 
> -release.

If the programmer knows a value isn't null, why not put the value in a 
nullable-reference in the first place?


> Also, it introduces more nesting.

Yes and no. It introduces an "if" statement for null checking, but only 
for nullable references. If you know your reference can't be null it 
should be non-nullable, and then you don't need to check.


> Also, unless the compiler's flow analysis is great, it's a nuisance -- 
> you can see that the error is bogus and have to insert extra checks.

First you're right, if the feature is implemented it should be well 
implemented. Second, if in a few place you don't want an "if" clause, 
you can always cast your nullable reference to a non-nullable one, 
explicitly bypassing the safeties. If you write a cast, you are making 
a consious decision of not checking for null, which is much better than 
the current situation where it's very easy to forget to check for null.


> It should be fine to provide a requireNotNull template and leave it at that.

It's fine to have such a template. But it's not nearly as useful.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/




More information about the Digitalmars-d mailing list