View mode: basic / threaded / horizontal-split · Log in · Help
February 21, 2008
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
"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
Re: My Kingdom For ...
"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
Re: My Kingdom For ...
"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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home