Mea Culpa

[Ary Borenszweig]

Jason House escribió:
> 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.

Or like T! in Spec# :-)