Mea Culpa

[Jason House]

Walter Bright wrote:

> I know that many of you have asked that the compiler diagnose an error
> for:
> 
>     Class C { }
>     C c;
>     if (c != null)
>         ...
> 
> because it will seg fault at runtime (depending on how opEqual() was
> written). I resisted because there is no way, in the general case, to
> detect at compile time if one of the operands will evaluate to null or
> not. But I finally thought "most of the cases, null is used directly",
> so I put in a test in the compiler which rejects class == and != with
> the literal null.
> 
> I found some errors in my own D code with it.
> 
> You guys were right.
> 
> The compiler will now also reject things like:
> 
>      if (c > null)
> 
> which make no sense.

While on the topic of null-based problems, are there any plans to address
either of the following issues?

1. Run-time debug mode checks for null references.
   (Maybe -debug=null or something...)

2. Any simplification of forcing non-null function inputs.
   Example:
     void foo(A a, B b, C c, D d)
     in{
       assert(a !is null, "foo can't accept null for 1st parameter");
       assert(b !is null, "foo can't accept null for 2nd parameter");
       assert(c !is null, "foo can't accept null for 3rd parameter");
       assert(d !is null, "foo can't accept null for 4th parameter");
     }
     body{...}

I know #1 was asked for a few times.  #2 is my own personal wish.  I find
that I'm usually too lazy to add !is null checks all over the place.  I
guess you could say it's the reverse of C#'s "T?" that allows nulls.