February 21, 2008 Re: My Kingdom For ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matti Niemenmaa | "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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | "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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | "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. |
Copyright © 1999-2021 by the D Language Foundation