"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in news:bjsbo9$2s5$1@digitaldaemon.com:

> "Riccardo De Agostini" <riccardo.de.agostini@email.it> ha scritto nel messaggio news:bjsb2s$1t3$1@digitaldaemon.com...
>> "MyObj a, b; if (a > b)" calls a.cmp(b) and you
>> don't even expect it to compare operators.
> 
> Should have been "pointers" instead of "operators". No more Chinese food for lunch, I promise. :)
> 
> Walter (I know you'll be reading this...): don't you think that "is" (as in "if (a is b)") would be better than "===" for pointer equality check? The !== operator might even be eliminated, or maybe substituted by "is_not", "isnot" or something of the kind. This would make things clearer for both C++ experienced programmers (since they wouldn't have to remember which is which between == and ===) and people learning D from scratch or maybe with a Basic/Pascal/whatever background.
> 
> Ric
> 
> 

This wouldn't make things clearer for C++ experienced programmers. They will just write "if (a == b)", because they are a not used to use the operator "is", some won't even know about it.

Riccardo De Agostini wrote:
> "Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio
> news:bjrf0m$1rpd$1@digitaldaemon.com...
> 
> (hmmm, this time I'm gonna get shot... :-) )
> 
> How about getting rid of === and !== and having a "is" operator which checks
> for equality of pointers?
> 
> if (a is b) printf("a points to the same object as b\n");
> 
> if (a == b) printf("a.eq(b) returned true\n");
> 
> Ric

I like this syntax a lot.  Python uses 'is' and 'is not' to test object identity, which is about as readable as it gets.

 -- andy

> The meaning of == vs === is a big problem. For C++, Java and C# programmers the current semantics poses subtle differences as D references feel more like C++ pointers, Java references or C# references than  C++ references.

Yes ...

> I think the meaning of == vs === should be swapped, it's just too subtle for all those C++ and Java programmers out there.

... NO!

That would take it even further away from C++ and more towards Java. IMO that would be worse, but even from an unbiased pov it just exchanges one complication for another.

We need == (equality), is (identity) and isa (type membership).

> Afterall, the reasons for the current semantics seems not too compelling, to me.
>
> Antti Sykari, had brought up some arguments why operator== should mean identity instead of equality: http://www.digitalmars.com/drn-bin/wwwnews?D/12295
>
>
> Farmer.
>

In article <bjth3u$1n2l$1@digitaldaemon.com>, Matthew Wilson says...
>
>> The meaning of == vs === is a big problem. For C++, Java and C# programmers the current semantics poses subtle differences as D references feel more like C++ pointers, Java references or C# references than  C++ references.
>
>Yes ...
>
>> I think the meaning of == vs === should be swapped, it's just too subtle for all those C++ and Java programmers out there.
>
>... NO!
>
>That would take it even further away from C++ and more towards Java. IMO that would be worse, but even from an unbiased pov it just exchanges one complication for another.
>
>We need == (equality), is (identity) and isa (type membership).
>
>> Afterall, the reasons for the current semantics seems not too compelling, to me.
>>
>> Antti Sykari, had brought up some arguments why operator== should mean identity instead of equality: http://www.digitalmars.com/drn-bin/wwwnews?D/12295

I'm with Matthew on this one.  I think '==' needs to remain a value comparison and '===' should be changed to 'is'.

The == and === debates originally happened a while back
in this forum.  I don't remember the all of the reasons
for the choice,  but one was for the syntax to remain consistent
with the syntax for arrays.  We wanted the comparison operators
to do element by element comparisons on arrays.  This is why you
can do convenient things like if(foo <= "fred") in D now.  == was
made a value comparison to remain consistent with the other
comparison operators.  It also made sense for the array and
object syntax to be consistent also so == was used as a value
comparison for objects too.  === was chosen to be the identity
comparison and as stated above I'd much prefer it to be 'is'.

I think a number of issues with == would go away if it was implemented like this.

if(a === b)
return true;
else if(a === null)
return false;
else if(b === null)
return false;
else // If a has an eq
return a.eq(b);

Patrick Down wrote:
> In article <bjth3u$1n2l$1@digitaldaemon.com>, Matthew Wilson says...
> 
>>>The meaning of == vs === is a big problem. For C++, Java and C#
>>>programmers the current semantics poses subtle differences as D references
>>>feel more like C++ pointers, Java references or C# references than  C++
>>>references.
>>
>>Yes ...
>>
>>
>>>I think the meaning of == vs === should be swapped, it's just too subtle
>>>for all those C++ and Java programmers out there.
>>
>>... NO!
>>
>>That would take it even further away from C++ and more towards Java. IMO
>>that would be worse, but even from an unbiased pov it just exchanges one
>>complication for another.
>>
>>We need == (equality), is (identity) and isa (type membership).
>>
>>
>>>Afterall, the reasons for the current semantics seems not too compelling,
>>>to me.
>>>
>>>Antti Sykari, had brought up some arguments why operator== should mean
>>>identity instead of equality:
>>>http://www.digitalmars.com/drn-bin/wwwnews?D/12295
> 
> 
> I'm with Matthew on this one.  I think '==' needs to remain a value
> comparison and '===' should be changed to 'is'.
> 
> The == and === debates originally happened a while back
> in this forum.  I don't remember the all of the reasons for the choice,  but one was for the syntax to remain consistent with the syntax for arrays.  We wanted the comparison operators to do element by element comparisons on arrays.  This is why you can do convenient things like if(foo <= "fred") in D now.  == was made a value comparison to remain consistent with the other comparison operators.  It also made sense for the array and
> object syntax to be consistent also so == was used as a value
> comparison for objects too.  === was chosen to be the identity
> comparison and as stated above I'd much prefer it to be 'is'.
> 
> I think a number of issues with == would go away if it was
> implemented like this.
> 
> if(a === b)
> return true;
> else if(a === null)
> return false;
> else if(b === null)
> return false;
> else // If a has an eq
> return a.eq(b);
> 

so ( a == null ) would always be false ?

>>
>> I think a number of issues with == would go away if it was
>> implemented like this.
>>
>> if(a === b)
>> return true;
>> else if(a === null)
>> return false;
>> else if(b === null)
>> return false;
>> else // If a has an eq
>> return a.eq(b);
>>
> 
> so ( a == null ) would always be false ?
> 
oops need more coffee, missed the first line
that is exactly what is needed
a == null equiv to a === null
assuming a != b is defined as !(a == b) that works too

Patrick Down wrote:
> In article <bjth3u$1n2l$1@digitaldaemon.com>, Matthew Wilson says...
> 
>>>The meaning of == vs === is a big problem. For C++, Java and C#
>>>programmers the current semantics poses subtle differences as D references
>>>feel more like C++ pointers, Java references or C# references than  C++
>>>references.
>>
>>Yes ...
>>
>>
>>>I think the meaning of == vs === should be swapped, it's just too subtle
>>>for all those C++ and Java programmers out there.
>>
>>... NO!
>>
>>That would take it even further away from C++ and more towards Java. IMO
>>that would be worse, but even from an unbiased pov it just exchanges one
>>complication for another.
>>
>>We need == (equality), is (identity) and isa (type membership).
>>
>>
>>>Afterall, the reasons for the current semantics seems not too compelling,
>>>to me.
>>>
>>>Antti Sykari, had brought up some arguments why operator== should mean
>>>identity instead of equality:
>>>http://www.digitalmars.com/drn-bin/wwwnews?D/12295
> 
> 
> I'm with Matthew on this one.  I think '==' needs to remain a value
> comparison and '===' should be changed to 'is'.
> 
> The == and === debates originally happened a while back
> in this forum.  I don't remember the all of the reasons for the choice,  but one was for the syntax to remain consistent with the syntax for arrays.  We wanted the comparison operators to do element by element comparisons on arrays.  This is why you can do convenient things like if(foo <= "fred") in D now.  == was made a value comparison to remain consistent with the other comparison operators.  It also made sense for the array and
> object syntax to be consistent also so == was used as a value
> comparison for objects too.  === was chosen to be the identity
> comparison and as stated above I'd much prefer it to be 'is'.
> 
> I think a number of issues with == would go away if it was
> implemented like this.
> 
> if(a === b)
> return true;
> else if(a === null)
> return false;
> else if(b === null)
> return false;
> else // If a has an eq
> return a.eq(b);
> 
if == was implemented as that I believe ===/!== can be dropped the rare cases when you do want to compare that two objects are the same object
would have to be ( &a == &b ) which is more visually obvious.

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjtmft$1ub4$1@digitaldaemon.com...
> if == was implemented as that I believe ===/!== can be dropped the rare cases when you do want to compare that two objects are the same object would have to be ( &a == &b ) which is more visually obvious.

I would like this better.  If you want to compare addresses, compare addresses... there is an address-of operator in D.

We need to be able to overload at least the < operator so we can control sorting order etc.

Sean

In article <bjvljt$1m5i$1@digitaldaemon.com>, Sean L. Palmer wrote:
> "Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjtmft$1ub4$1@digitaldaemon.com...
>> if == was implemented as that I believe ===/!== can be dropped the rare cases when you do want to compare that two objects are the same object would have to be ( &a == &b ) which is more visually obvious.
> 
> I would like this better.  If you want to compare addresses, compare addresses... there is an address-of operator in D.

Which brings us the problem that we should treat objects the same as structs. But we cannot, because we don't know their actual size beforehand and therefore cannot put them on the stack. So class objects remain, practically, pointers.

And taking a pointer of the object would be like taking an address of a smart pointer class in C++. Which one wouldn't under normal circumstances do.

It's funny, I never really thought it was legal to take an address of an object, but it works:

void main()
{
    Object o1 = new Object;
    Object o2 = o1;

    printf("o1 == %08x, o2 == %08x, &o1 == %08x, &o2 == %08x\n",
        o1, o2, &o1, &o2);
}

o1 == 00870fd0, o2 == 00870fd0, &o1 == 0012ff30, &o2 == 0012ff34

So &o1 !== &o2 but o1 != o2. In fact, &o1 == &o2 implies o1 === o2, which in turn implies o1 == o2. (Well, except if o1 is null, in which case the comparison crashes. So much for the fine theory) And &o1 == &o2 in fact is true only if it's the same variable.

-Antti

Antti Sykäri wrote:
> In article <bjvljt$1m5i$1@digitaldaemon.com>, Sean L. Palmer wrote:
> 
>>"Mike Wynn" <mike@l8night.co.uk> wrote in message
>>news:bjtmft$1ub4$1@digitaldaemon.com...
>>
>>>if == was implemented as that I believe ===/!== can be dropped the rare
>>>cases when you do want to compare that two objects are the same object
>>>would have to be ( &a == &b ) which is more visually obvious.
>>
>>I would like this better.  If you want to compare addresses, compare
>>addresses... there is an address-of operator in D.
> 
> 
> Which brings us the problem that we should treat objects the same as structs.
> But we cannot, because we don't know their actual size beforehand and therefore
> cannot put them on the stack. So class objects remain, practically, pointers.
> 
> And taking a pointer of the object would be like taking an address of a smart
> pointer class in C++. Which one wouldn't under normal circumstances do.
> 
> It's funny, I never really thought it was legal to take an address of an
> object, but it works:
> 
> void main()
> {
>     Object o1 = new Object;
>     Object o2 = o1;
> 
>     printf("o1 == %08x, o2 == %08x, &o1 == %08x, &o2 == %08x\n",
>         o1, o2, &o1, &o2);
> }
> 
> o1 == 00870fd0, o2 == 00870fd0, &o1 == 0012ff30, &o2 == 0012ff34
> 
> So &o1 !== &o2 but o1 != o2. In fact, &o1 == &o2 implies o1 === o2, which in
> turn implies o1 == o2. (Well, except if o1 is null, in which case the
> comparison crashes. So much for the fine theory) And &o1 == &o2 in fact is true
> only if it's the same variable.
> 
> -Antti
> 

your right ... currently &o is (void*)o

so what I wrote as ( &a == &b ) is infact
( cast(void*)a == cast(void*)b )