www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11161] New: If `opEquals` is not defined, compiler should translate struct objects equality to member-wise equality even if there is `alias this`

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161

           Summary: If `opEquals` is not defined, compiler should
                    translate struct objects equality to member-wise
                    equality even if there is `alias this`
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: verylonglogin.reg gmail.com



11:59:38 MSD ---
---
struct S {
    bool opEquals(ref const S) { return false; } 
}
struct T {
    S s;
    int value;
    alias value this;
}

void main() {
    T t1, t2;
    assert(t1.tupleof != t2.tupleof);
    assert(t1 != t2); // fails
}
---

If this behavior is expected, please write the reasons shortly and change it to
documentation issue unless this feature is documented.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 03 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PDT ---
I would expect that alias this would have zero effect on == save for when
comparing with a value of the type that's being aliased instead of with a value
of the same type.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |spec
          Component|DMD                         |websites
            Summary|If `opEquals` is not        |Document the default struct
                   |defined, compiler should    |equality comparison and
                   |translate struct objects    |operator overloading
                   |equality to member-wise     |
                   |equality even if there is   |
                   |`alias this`                |





 ---
 struct S {
     bool opEquals(ref const S) { return false; } 
 }
 struct T {
     S s;
     int value;
     alias value this;
 }
 
 void main() {
     T t1, t2;
     assert(t1.tupleof != t2.tupleof);
     assert(t1 != t2); // fails
 }
 ---
 
 If this behavior is expected, please write the reasons shortly and change it to
 documentation issue unless this feature is documented.


For the expression `t1 != t2`, the semantic analysis is done in the following
order:

1. Find opEquals method from the type of operands
2. If 'alias this' declaration exists, compiler tries to resolve equality
operation via alias this. -> `t1.value != t2.value` is tested, and succeeds to
compile.
3. If any opEquals and comparable 'alias this' is not found, the struct
equality comparison is rewritten to their each field comparison.


is precedence than the default struct equality operation (== field-wise
comparison). Historically

Historically:
- By bug 3789, the default comparison behavior was changed from bitwise to
  member-wise.
- By bug 10037, the operator overload resolution precedence order was fixed
  (default member-wise comparison does not hide explicitly defined alias this).

Therefore, current behavior is expected.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161






 I would expect that alias this would have zero effect on == save for when
 comparing with a value of the type that's being aliased instead of with a value
 of the same type.


'alias this' should be considered for operator overloading. If not, sub-typing
by using 'alias this' won't work anymore.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161




PDT ---

 'alias this' should be considered for operator overloading. If not, sub-typing


by using 'alias this' won't work anymore.

I would expect sub-typing via alias this to only come into effect when the
values being compared were of different types. So,

struct S
{
    bool opEquals(ref const S) { return false; } 
}
struct T
{
    S s;
    int value;
    alias value this;
}

void main()
{
    S s1;
    S s2;
    int i;

    //Uses built-in opEquals, because the types match
    auto result1 = s1 == s2;

    //Uses alias this because it's not comparing with another S
    auto result2 = s1 == i;
}

I don't understand why alias this would even come into effect until you're
dealing with a type other than S. As I understand it, alias this is for when
the original type doesn't work, in which case the conversion is done if that
will work instead. And that doesn't apply here.

I'd also expect the compiler to always define a default opEquals for structs if
you don't define one. And that's what it does when there's no alias this
involved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161






 For the expression `t1 != t2`, the semantic analysis is done in the following
 order:
 
 1. Find opEquals method from the type of operands
 2. If 'alias this' declaration exists, compiler tries to resolve equality
 operation via alias this. -> `t1.value != t2.value` is tested, and succeeds to
 compile.


I think this is completely bogus. Doing this means an alias this takes
precedence over the type that holds it, and it should *never* happen. An alias
this should never ever EVER take precedence over the base type.

Here are some rebuttals to the above mentioned behavior.


a struct. Today, it was mostly hijacked to instead do implicit conversion,
where a struct can pass for some other type.

The very "standard" scenario of:

//----
struct Base
{
    int i;
}
struct Derived
{
    Base b;
    alias b this;
    int j;
}

void main()
{
    Base b = {0};
    Derived d1 = {b, 1};
    Derived d2 = {b, 2};
    assert(d1 != d2); //This fails
}
//----

The above assert is going to fail. This is completely unacceptable. Derived is
a "subkind" of Base: It's Base plus some more. With the current behavior
though, Derived is straight up treated as a Base, and everything that makes it
a Derived is forgotten.


this - I think it's obvious that opAssign and opEqual should follow the same
set of rules.


spectacualrly.


to implement. Indeed, only the type that is resolved by alias this should be
taken into account.

Because of the above reason, I think that "alias this" most certainly should
*not* be considered before checking if "T == T" is legal.

Heck, I don't think it should be considered at *all* for "T == T": opAssign
doesn't check.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 06 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11161


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major



11:31:21 MSK ---


 1. Find opEquals method from the type of operands
 2. If 'alias this' declaration exists, compiler tries to resolve equality
 operation via alias this. -> `t1.value != t2.value` is tested, and succeeds to
 compile.


Just to be clear, currently we have this:
---
struct S
{
    int i, j;
    alias j this;
}

void main()
{
    S s1 = {0}, s2 = {1};
    assert(s1 == s2); // ok, resolved as `s1.j == s2.j`
}
---
And I'm quite sure it must be clearly documented.

Also it should be mentioned one have to add:
---
bool opEquals(in typeof(this) other)
{ return this.tupleof == other.tupleof; }
---
if "old" comparison behavior is needed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 05 2013