www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Default implementation of opEquals

reply Mark <smarksc gmail.com> writes:
I'm going over the Object class methods and I have a few concerns 
about the opEquals method.

First, what should be the default implementation of opEquals? The 
specification (see 
https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

"If opEquals is not specified, the compiler provides a default 
version that does member-wise comparison"

But this doesn't appear to be the case (at least with dmd). So I 
went and checked the module in 
https://github.com/dlang/druntime/blob/master/src/object.d. It 
implements opEquals by comparing references (obj1 is obj2), not 
by member-wise comparison.

Wouldn't member-wise comparison be a more intuitive default?
Oct 07 2016
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:

 I'm going over the Object class methods and I have a few 
 concerns about the opEquals method.

 First, what should be the default implementation of opEquals? 
 The specification (see 
 https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"

 But this doesn't appear to be the case (at least with dmd). So 
 I went and checked the module in 
 https://github.com/dlang/druntime/blob/master/src/object.d. It 
 implements opEquals by comparing references (obj1 is obj2), not 
 by member-wise comparison.

 Wouldn't member-wise comparison be a more intuitive default?


For structs it provides memberwise comparison for classes it uses 
pointer-identity
Oct 07 2016
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:

 I'm going over the Object class methods and I have a few 
 concerns about the opEquals method.

 First, what should be the default implementation of opEquals? 
 The specification (see 
 https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"

 But this doesn't appear to be the case (at least with dmd). So 
 I went and checked the module in 
 https://github.com/dlang/druntime/blob/master/src/object.d. It 
 implements opEquals by comparing references (obj1 is obj2), not 
 by member-wise comparison.

 Wouldn't member-wise comparison be a more intuitive default?


This is a problem with the spec that needs to be fixed. It's well 
known that member wise comparison default is for structs and 
objects just compare the reference. I believe this has always 
been the intended behavior.
Oct 07 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:

 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"


That's referring to structs. For classes, it gives an identity 
comparison function here: 
https://dlang.org/spec/operatoroverloading.html#equals


 Wouldn't member-wise comparison be a more intuitive default?


Classes are supposed to represent encapsulated objects where you 
don't look at the members from the outside, so that might be 
surprising in a different way.
Oct 07 2016
parent reply Mark <smarksc gmail.com> writes:
On Friday, 7 October 2016 at 12:34:34 UTC, Adam D. Ruppe wrote:

 On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:

 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"


 That's referring to structs. For classes, it gives an identity 
 comparison function here: 
 https://dlang.org/spec/operatoroverloading.html#equals


 Wouldn't member-wise comparison be a more intuitive default?


 Classes are supposed to represent encapsulated objects where 
 you don't look at the members from the outside, so that might 
 be surprising in a different way.


Okay, that makes sense.

I find it slightly annoying that the default opCmp throws an 
exception whereas the default opEquals doesn't, but if both of 
these functions are to be removed from Object, as Jonathan M 
Davis stipulates, then all of this is a non-issue.
Oct 07 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 07, 2016 13:41:00 Mark via Digitalmars-d wrote:

 I find it slightly annoying that the default opCmp throws an
 exception whereas the default opEquals doesn't, but if both of
 these functions are to be removed from Object, as Jonathan M
 Davis stipulates, then all of this is a non-issue.


It's the plan anyway. It fundamentally doesn't work to have them on Object
and be flexible with attributes, so it was decided a while ago that they
need to go. Unfortunately, not a lot has been done to get there yet, and
what has been done hasn't been merged. Fortunately, one of the major issues
is that (if I understand correctly) we really need a templatized AA
implementantion to be able to remove the functions from Object, and a fair
bit of work _has_ gone towards that, and it looks like we may have it in the
reasonably near future.

But there's still plenty to figure out out about how we go about this,
because a big part of the problem is how to do it without breaking code.
Once the groundwork has been laid, we could easily just remove the
functions, but that would break a lot of code, which we obviously don't
want. So, at some point here, all of that is going to need to be discussed
and a plan formed.

For now though, it sounds like the AA implementation is coming along, and
there is a PR to templatize opEquals so that it's at least possible to
declare opEquals without overriding the one on Object.

- Jonathan M Davis
Oct 07 2016
parent Mark <smarksc gmail.com> writes:
On Friday, 7 October 2016 at 14:04:10 UTC, Jonathan M Davis wrote:

 On Friday, October 07, 2016 13:41:00 Mark via Digitalmars-d 
 wrote:

 [...]


 It's the plan anyway. It fundamentally doesn't work to have 
 them on Object and be flexible with attributes, so it was 
 decided a while ago that they need to go. Unfortunately, not a 
 lot has been done to get there yet, and what has been done 
 hasn't been merged. Fortunately, one of the major issues is 
 that (if I understand correctly) we really need a templatized 
 AA implementantion to be able to remove the functions from 
 Object, and a fair bit of work _has_ gone towards that, and it 
 looks like we may have it in the reasonably near future.

 [...]


Wish I could help, but I'm still a D newbie. :x
Oct 07 2016
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 07, 2016 12:04:09 Mark via Digitalmars-d wrote:

 I'm going over the Object class methods and I have a few concerns
 about the opEquals method.

 First, what should be the default implementation of opEquals? The
 specification (see
 https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

 "If opEquals is not specified, the compiler provides a default
 version that does member-wise comparison"

 But this doesn't appear to be the case (at least with dmd). So I
 went and checked the module in
 https://github.com/dlang/druntime/blob/master/src/object.d. It
 implements opEquals by comparing references (obj1 is obj2), not
 by member-wise comparison.

 Wouldn't member-wise comparison be a more intuitive default?


The current behavior is what it's always been and actually is consistent

eventually remove opEquals from Object.

https://issues.dlang.org/show_bug.cgi?id=9769

Speaking of which, this PR to templatize the free function version of
opEquals needs some folks to review it and merge it:

https://github.com/dlang/druntime/pull/1439

It's just been languishing even though it's theoretically ready to go and
has been for months.

- Jonathan M Davis
Oct 07 2016