February 21, 2008
Janice Caron escribió:
> On 21/02/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> I'd vote enthusiastically for issuing a warning, but I don't like the
>>  idea of changing behavior just for that one special case.
> 
> I'd be inclined to agree, but for the fact that D doesn't have warnings.
> 
> So, you could say, second best option, make it a compile error.
> 
>     if (c == null) // ERROR
> 
> Anyone see any problem with that?

I did it in Descent as a warning, but then it appeared in lot of places in phobos, so that definitely doesn't work (I removed it from Descent). It must only be an error if c is a class reference. If it's a pointer, it's ok. Any other case?
February 21, 2008
On 21/02/2008, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>  It must only be an error if c is a class reference. If it's a pointer,
>  it's ok

Why? if (p is null) works for pointers too, and in template programming, the compiler doesn't always know what p is anyway.
February 21, 2008
Janice Caron escribió:
> On 21/02/2008, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>  It must only be an error if c is a class reference. If it's a pointer,
>>  it's ok
> 
> Why? if (p is null) works for pointers too

That's what I said: "If it's a pointer, it's ok" (don't show a warning/error). Or are you saying something completely different?

, and in template
> programming, the compiler doesn't always know what p is anyway.

Templates aren't evaluated until they are instantiated, so the compiler can do the same check only in instantiations.
February 21, 2008
On 21/02/2008, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> >>  It must only be an error if c is a class reference. If it's a pointer,
>  >>  it's ok
>
> > Why? if (p is null) works for pointers too
>
> That's what I said: "If it's a pointer, it's ok" (don't show a
>  warning/error). Or are you saying something completely different?

I guess I was. I suppose I was saying, let's make "== null" illegal for /all/ types. "== null" just isn't needed, because in /all/ cases, "is null" works.
February 21, 2008
Janice Caron escribió:
> On 21/02/2008, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>>>  It must only be an error if c is a class reference. If it's a pointer,
>>  >>  it's ok
>>
>>> Why? if (p is null) works for pointers too
>> That's what I said: "If it's a pointer, it's ok" (don't show a
>>  warning/error). Or are you saying something completely different?
> 
> I guess I was. I suppose I was saying, let's make "== null" illegal
> for /all/ types. "== null" just isn't needed, because in /all/ cases,
> "is null" works.

That's even better than an error. :-)

But programmers are used to use "==" for comparisons with null... Another alternative would be for the compiler to rewrite "== null" as "is null", always.
February 21, 2008
On Thu, 21 Feb 2008 23:55:29 +0100, Ary Borenszweig wrote:

>> I guess I was. I suppose I was saying, let's make "== null" illegal for /all/ types. "== null" just isn't needed, because in /all/ cases, "is null" works.
> 
> That's even better than an error. :-)
> 
> But programmers are used to use "==" for comparisons with null... Another alternative would be for the compiler to rewrite "== null" as "is null", always.

For what its worth, I'm also in the camp that feels that "== null" and "is null" should be treated semantically the same by the language. I realize that his would add a bit of complexity in a compiler that automatically translates "==" into an opEquals() call.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/02/2008 9:58:03 AM
February 21, 2008
On 21/02/2008, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>  But programmers are used to use "==" for comparisons with null...
>  Another alternative would be for the compiler to rewrite "== null" as
>  "is null", always.

Yep. That works for me too.

Of course, what I'd /really/ prefer is a runtime check (in debug builds only, of course) for all null dereferences. I see it as basically the same as array bounds checking - for speed, you don't want it in a final release, but during development, you sacrifice the speed and let the compiler help out. That would be useful, because not only would it catch ==null, but it would also catch .member and .func(), and you'd get a nice error message telling what line of what file threw the exception.

And while we're on the subject of random falling over, am I the only one who gets infuriated by the occasional "Win32 Exception" halting a program with no further explanation? They happen when the flow of execution hits the bottom of a function without returning, when it's supposed to return something. I'm surprised we can't catch those at compile time, but even a nice D Exception throw at runtime (...again, in a debug build only...) would be useful.
February 21, 2008
"Matti Niemenmaa" <see_signature@for.real.address> wrote in message news:fpkebq$274u$1@digitalmars.com...

> Imagine the increased clarity:
>
> return *a !- *b ? *a!**b : foo!(int)!&a;

This is clear?

News to me!


February 21, 2008
"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.47.1203635455.2351.digitalmars-d@puremagic.com...

> And while we're on the subject of random falling over, am I the only one who gets infuriated by the occasional "Win32 Exception" halting a program with no further explanation? They happen when the flow of execution hits the bottom of a function without returning, when it's supposed to return something. I'm surprised we can't catch those at compile time, but even a nice D Exception throw at runtime (...again, in a debug build only...) would be useful.

Except that it _does_ throw an exception to that effect in a debug build. God, have you even _used_ D?


February 21, 2008
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:fpl0sc$hbe$1@digitalmars.com...
> "Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.47.1203635455.2351.digitalmars-d@puremagic.com...
>
>> And while we're on the subject of random falling over, am I the only one who gets infuriated by the occasional "Win32 Exception" halting a program with no further explanation? They happen when the flow of execution hits the bottom of a function without returning, when it's supposed to return something. I'm surprised we can't catch those at compile time, but even a nice D Exception throw at runtime (...again, in a debug build only...) would be useful.
>
> Except that it _does_ throw an exception to that effect in a debug build. God, have you even _used_ D?
>

Sorry for being a bit harsh.  I'm just defensive when people criticize D for not doing things it should when it does do them.