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.

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.

Yea!  It helps to eat your own dog food once in a while.

--bb

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.

Thanks! But it did help me develop the good habit of always putting null on the left hand side of comparison tests.

Thanks!

I wanted to implement that functionality by adding it to the port in Descent, but I reverted because then some errors appeared in phobos, and I thought I got the logic wrong. Maybe those errors were legitimate after all... :)

Walter Bright escribió:
> 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.

On Tue, 04 Mar 2008 22:56:24 -0800, Walter Bright wrote:

> You guys were right.

Thanks, I appreciate your candor.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Great! Thanks :)

Walter,

Thank you thank you.

-Steve

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.

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# :-)

Ary Borenszweig:
> Or like T! in Spec# :-)

You may take a look at how Cyclone too manages such problem: http://en.wikipedia.org/wiki/Cyclone_programming_language#Pointer.2Freference_types

Bye,
bearophile