From the D Doc:

=====================================
Note: Comparing a reference to a class object against null should be done
as:
if (a === null)
and not as:
if (a == null)
The latter is converted to:
if (a.opCmp (null))
which will fail if opCmp () is a virtual function.
=======================================

When people from C++/Java write 'if (a == null)', and get a core dump, they will be easily confused: what's going wrong?  Because under the hood, it's a func call with null passed as parameter!  You have to think twice to realized this.

Why should we introduce such a confusing feature which can mislead C++/Java programmer easily?  In many other cases D *intentionally* work the same way C++/Java works, so people familiar with C++/Java can move to D comfortably.  But why make '===' a special case?

My suggestions:

1)  restore the old semantics of "==" as reference comparison; and

2a) convert the new '===' operator to 'opCmp ()'; or
2b) abadon '===' completely, let the programmer call 'opCmp()' explicitly; (just
as in Java, you call `equals()' explicitly)

So C++/Java programmers will make less mistakes.

I'd prefer 1) and 2b), what do you think?

no@where.com wrote:
> 
> When people from C++/Java write 'if (a == null)', and get a core dump, they will
> be easily confused: what's going wrong?  Because under the hood, it's a func
> call with null passed as parameter!  You have to think twice to realized this.

This is an old, sore issue that has been discussed many, many times in the past, and has already been resolved, just not in the way that some of us would have preferred. :)

Without going too deeply into the gory details, == and != test for equivalence.  === and !== test for identity.  It's perfectly consistent, and so should stay as it is.

Your problem arises from the fact that Object defines opCmp, which means that /all object references/ can be compared with ==, !=, >, <, and the rest.  If not for this, the expression "a==b" would be a compile time error for types which do not explicitly define opCmp.

 -- andy

//! My 2 bits
I'd have a different proposal... What might be done, is some more checking in the debug build. I'd say this is almost like array bounds checking, the null-ness check might be done for the == (and the rest of opCmp-defined) operators in debug, but removed in the release build. I'd prefer to see a 'nice' error with full info instead of an Access Violation. Something like the ArrayBoundsError would be just fine for me.


Tom



no@where.com wrote:
> From the D Doc:
> 
> =====================================
> Note: Comparing a reference to a class object against null should be done
> as:
> if (a === null)
> and not as:
> if (a == null)
> The latter is converted to:
> if (a.opCmp (null))
> which will fail if opCmp () is a virtual function.
> =======================================
> 
> When people from C++/Java write 'if (a == null)', and get a core dump, they will
> be easily confused: what's going wrong?  Because under the hood, it's a func
> call with null passed as parameter!  You have to think twice to realized this.
> 
> Why should we introduce such a confusing feature which can mislead C++/Java
> programmer easily?  In many other cases D *intentionally* work the same way
> C++/Java works, so people familiar with C++/Java can move to D comfortably.  But
> why make '===' a special case?
> 
> My suggestions:
> 
> 1)  restore the old semantics of "==" as reference comparison; and
> 
> 2a) convert the new '===' operator to 'opCmp ()'; or
> 2b) abadon '===' completely, let the programmer call 'opCmp()' explicitly; (just
> as in Java, you call `equals()' explicitly)
> 
> So C++/Java programmers will make less mistakes.
> 
> I'd prefer 1) and 2b), what do you think?

>I'd prefer 1) and 2b), what do you think?

or 3) have the compiler explicitly check for null comparisons and issue a ... ummm what to call it... a compiler-generated bug report... saying that line will fail if the other value happens to be null. That will catch most ported code. I know Walter dislikes warnings from compilers so I think I'll call it a "compiler-generated bug report" :-)

For 1.0 in its current incarnation I think there's a necessity for checking for the specific expression

a == null

and at least issuing a warning...  it would be a simple search over parse trees to catch this common mistake at COMPILE (rather than run)time.  Clearly there are (rare, unnecessary since you can call opCmp) times when you want to pass null into an opCMP but then perhaps having a cast or something to illustrate that you are not making a mistake

a = cast(Object)null

like so.

I guess we *could* have a lint program do this for us--but if/when this magical lint program gets made...and decides NOT to spit a billion warnings out for otherwise-working projects is a mystery.

An alternative would be making C and pascal programmers less likely to fail (in C == was always bitwise compare)

how about changing


a=b (read a gets b)
to
a := b;

and a==b (read a opCmp b)
to
a=b

and lastly
a===b (read a (pointer or otherwise) bitwise equals b)
to
a==b

two equals signs is already a hack--but 3...c'mon! that's making 3 separate operators consisting of various numbers of the same char... 2 already cause a great number of errors amongst C and C++ newbies from all backgrounds.




h3r3tic wrote:
> //! My 2 bits
> I'd have a different proposal... What might be done, is some more checking in the debug build. I'd say this is almost like array bounds checking, the null-ness check might be done for the == (and the rest of opCmp-defined) operators in debug, but removed in the release build. I'd prefer to see a 'nice' error with full info instead of an Access Violation. Something like the ArrayBoundsError would be just fine for me.
> 
> 
> Tom
> 
> 
> 
> no@where.com wrote:
> 
>> From the D Doc:
>>
>> =====================================
>> Note: Comparing a reference to a class object against null should be done
>> as:
>> if (a === null)
>> and not as:
>> if (a == null)
>> The latter is converted to:
>> if (a.opCmp (null))
>> which will fail if opCmp () is a virtual function.
>> =======================================
>>
>> When people from C++/Java write 'if (a == null)', and get a core dump, they will
>> be easily confused: what's going wrong?  Because under the hood, it's a func
>> call with null passed as parameter!  You have to think twice to realized this.
>>
>> Why should we introduce such a confusing feature which can mislead C++/Java
>> programmer easily?  In many other cases D *intentionally* work the same way
>> C++/Java works, so people familiar with C++/Java can move to D comfortably.  But
>> why make '===' a special case?
>>
>> My suggestions:
>>
>> 1)  restore the old semantics of "==" as reference comparison; and
>>
>> 2a) convert the new '===' operator to 'opCmp ()'; or
>> 2b) abadon '===' completely, let the programmer call 'opCmp()' explicitly; (just
>> as in Java, you call `equals()' explicitly)
>>
>> So C++/Java programmers will make less mistakes.
>>
>> I'd prefer 1) and 2b), what do you think?

Daniel Horn wrote:
> For 1.0 in its current incarnation I think there's a necessity for checking for the specific expression
> 
> a == null
> 
> and at least issuing a warning... 

I agree - the compiler should do whatever it can to catch code that is obviously going to AV or something.  But for as long as Walter thinks warnings are a Bad Thing, it'll have to be an error....

> it would be a simple search over parse trees to catch this common mistake at COMPILE (rather than run)time.  Clearly there are (rare, unnecessary since you can call opCmp) times when you want to pass null into an opCMP but then perhaps having a cast or something to illustrate that you are not making a mistake
> 
> a = cast(Object)null

Which you indeed are, albeit by dropping an '='.

<snip>
> how about changing
> 
> a=b (read a gets b)
> to
> a := b;
> 
> and a==b (read a opCmp b)
> to
> a=b
> 
> and lastly
> a===b (read a (pointer or otherwise) bitwise equals b)
> to
> a==b
<snip top of upside-down reply>

You may be up for completely changing the meaning of every D program ever written.  But I'm quite sure most of us aren't.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Daniel Horn wrote:

> I guess we *could* have a lint program do this for us--but if/when this magical lint program gets made...and decides NOT to spit a billion warnings out for otherwise-working projects is a mystery.

D should have all "warnings" enabled by default, as part of the design.

http://www.digitalmars.com/d/overview.html:
> No Warnings
> D compilers will not generate warnings for questionable code.
> Code will either be acceptable to the compiler or it will not be.
> This will eliminate any debate about which warnings are valid
> errors and which are not, and any debate about what to do with them.
> The need for compiler warnings is symptomatic of poor language design.

So all warnings and lint should be enabled by default, and give errors.

> two equals signs is already a hack--but 3...c'mon! that's making 3 separate operators consisting of various numbers of the same char... 2 already cause a great number of errors amongst C and C++ newbies from all backgrounds.

I thought that "===" was deprecated in favor of "is" ? (for TOKidentity)
http://www.digitalmars.com/d/expression.html#EqualExpression

But I also think that the compiler should be able to catch "foo == null"
I mean, it already catches the "if (a = b)" typo? (not a boolean result)

--anders

PS. The only problem was there isn't such a token for TOKnotidentity.
    But something like "isnt" should do, I suppose ? Or perhaps "aint".
    Or one of the syntactically horrible "is not" or "isn't" (not alnum)
    The current workaround is to use: !(a is b), which of course works.

Daniel Horn wrote:

> how about changing
> 
> a=b (read a gets b)
> to
> a := b;
> 
> and a==b (read a opCmp b)
> to
> a=b

If you want Pascal, you know where to get it... ?

Also,
a=b reads "b is assigned to a" (Assign Expression)
a==b reads as "a.opEquals(b)" (Equality Expression)

Then again,
o==null reads* "false", but
null==o reads "segfault" ;-)

* assuming: assert(o != null)

> and lastly
> a===b (read a (pointer or otherwise) bitwise equals b)
> to
> a==b

But '===' or 'is' checks for identity, not for equality!

http://www.digitalmars.com/d/expression.html#EqualExpression (Identity)

> For operand types other than class objects, static or dynamic arrays,
> identity is defined as being the same as equality.
> 
> For class objects, identity is defined as the object references are
> for the same object. Null class objects can be compared with is.
> 
> For static and dynamic arrays, identity is defined as referring to
> the same array elements.

The problem is that identity and equality are confused.
Changing the token names does not help with this issue...


For a Java programmer, the D rules for objects are strange.
Of course, the Java rules are a little weird too - as in:

http://www.witscale.com/scjp_studynotes/code_examples/chapter3/string_equality.html

Then again, that's partly because all arrays and strings are
objects in Java. And partly since it doesn't have op overloads ?

--anders


PS. http://www.gnu-pascal.de/gpc/h-index.html (GPC)
    http://www.microbizz.nl/gpc.html (Mac OS X)
    http://www.freepascal.org/

Anders F Björklund wrote:
> Of course, the Java rules are a little weird too - as in:
> 
> http://www.witscale.com/scjp_studynotes/code_examples/chapter3/string_equality.html 
> 
> Then again, that's partly because all arrays and strings are
> objects in Java. And partly since it doesn't have op overloads ?


  Actually the people who created Java are the only ones who can (and have) overloaded ops. Your example is thus an example of bad operator overloading which is (fortunately) limited in Java. It keeps the code away from C++/D stuff like:

----------------------------------------------------------------
  ...
  Apple a = new Apple(1);
  Orange o = new Orange(1);
  if( a > o )
  ...
----------------------------------------------------------------

Some notes on comparing apples and oranges:

http://www.people.virginia.edu/~rjh9u/apporang.html
http://bmj.bmjjournals.com/cgi/content/full/321/7276/1569

parabolis wrote:

>   Actually the people who created Java are the only ones who can (and have) overloaded ops. Your example is thus an example of bad operator overloading which is (fortunately) limited in Java.

If James Gosling can overload "plus" (+) to mean string concat,
Bjarne Stroustrup can use bit shifts (<< >>) to do stream I/O,
and Walter Bright can overload "not" (~) to mean concatenation -

then why should the rest of us be left out of all the fun ? :-)


But I am not sure I understand what you mean, since the default
implementation of equals in Java is to just use object identity.
And == works very differently for integers and strings there ?

Java's policy is just to "stay out of anything that can be misused"

--anders