www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3789] New: comparing a struct with an array member does a bitwise compare

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

           Summary: comparing a struct with an array member does a bitwise
                    compare
           Product: D
           Version: 2.040
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: schveiguy yahoo.com



12:08:23 PST ---
If you have a struct that does not define opEquals, but which contains a member
that defines opEquals, that member's opEquals is called when comparing the
struct.

However, arrays are still bitwise compared.  Example:

struct String
{
    char[] data;
}

void main ()
{
    auto foo = String("foo".dup);
    auto bar = String("foo".dup);

    assert(bar.data == foo.data);
    assert(bar == foo, "oops structs aren't equal");
}

results in the second assert failing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 09 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au



Arrays don't have a an opEquals overloaded operator. What's the bug?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




14:37:33 PST ---
that is an unimportant technical difference.  The semantic meaning of the
feature is that if you have a type T, and a struct S fully defined as:

struct S
{
  T member;
}

Then this assert should always pass:

S s1, s2;
... // initialize s1 and s2 to whatever you want
assert((s1 == s2) is (s1.member == s2.member));

Bitwise compare happens to be the comparison operator for all builtins except
for floating point and arrays.  Although opEquals isn't defined, they certainly
have special comparison operators, and those should be invoked when comparing
containing structs.  This is the principle of least surprise, especially when
arrays back types like strings.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


iorlas <denis.tomilin gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |denis.tomilin gmail.com




 Arrays don't have a an opEquals overloaded operator. What's the bug?
Not a bug, only not implemented part of comparison. Ofc it must be. Throws error or comparison each element through opEqual of elements type. Maybe now its not a critical, but in future it can block some code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


Simen Kjaeraas <simen.kjaras gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha yahoo.com



PST ---
*** Issue 5313 has been marked as a duplicate of this issue. ***

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


Simen Kjaeraas <simen.kjaras gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha yahoo.com
                 CC|                            |simen.kjaras gmail.com



PST ---
*** Issue 5313 has been marked as a duplicate of this issue. ***


PST ---
*** Issue 4988 has been marked as a duplicate of this issue. ***

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


Simen Kjaeraas <simen.kjaras gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Version|2.040                       |D2
            Summary|comparing a struct with an  |Structs members that
                   |array member does a bitwise |require non-bitwise
                   |compare                     |comparison not correctly
                   |                            |compared
           Severity|normal                      |major



PST ---
Making this the main bug for erroneous bitwise comparison of structs. There
were at least 4 in total.

List of things that do not work:

floating-point members
array members (including strings)

List of things that do work:

any member that uses bitwise comparison
member structs that have overloaded opEquals

The latter suggests that this should work for floating point numbers and arrays
too.

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


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



Maybe issue 5519 should be merged with this one.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




PST ---
*** Issue 5519 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




*** Issue 6812 has been marked as a duplicate of this issue. ***

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




---
From bug 6812:


 List of things that do not work:
 
 floating-point members
 array members (including strings)
+ member classes that have overloaded opEquals
 List of things that do work:
 
 any member that uses bitwise comparison
 member structs that have overloaded opEquals
-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |All
         Depends on|                            |1824



---
Test case.

void main()
{
    static struct Float
    {
        double x;
    }
    Float f;
    assert(f.x != f.x); // NaN != NaN
    assert(f != f);     // Fails, should pass

    static struct Array
    {
        int[] x;
    }
    Array a1 = Array([1,2,3].dup);
    Array a2 = Array([1,2,3].dup);
    assert(a1.x !is a2.x);
    assert(a1.x == a2.x);
    assert(a1 == a2);   // Fails, should pass

    static struct Class
    {
        Object x;
    }
    static class X
    {
        bool opEquals(Object o){ return true; }
    }

    Class c1a = Class(new Object());
    Class c2a = Class(new Object());
    assert(c1a.x !is c2a.x);
    assert(c1a.x != c2a.x);
    assert(c1a != c2a); // Pass, Object.opEquals works like bitwise compare

    Class c1b = Class(new X());
    Class c2b = Class(new X());
    assert(c1b.x !is c2b.x);
    assert(c1b.x == c2b.x);
    assert(c1b == c2b); // Fails, should pass
}

To fix the comparison behavior of a struct that has classes as members,
we need to fix the bug 1824 first.

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch



---
https://github.com/D-Programming-Language/dmd/pull/387

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




*** Issue 7089 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




---
*** Issue 7342 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




This is an answer to Walter to Bug 7783 :


 In the absense of a user-defined opEquals for the struct, equality is defined
 as a bitwise compare. This is working as expected. Not a bug.
I agree, it's not a DMD implementation bug because here it's working as designed. But I have voted bug 3789 time ago because I consider this in top 15 of the design decisions to fix/change, because this is a large source of bugs, it's unnatural. D is designed to be safe on default. Not comparing the strings as strings in the following code breaks the Principle of least astonishment: struct Foo { string name; bool b; } void main() { auto a = Foo("foobar".idup, true); auto b = Foo("foobar".idup, true); assert(a == b); } For me the only acceptable alternative to fixing Bug 3789 is statically disallowing the equal operator (==) in such cases. D language has the "is" for the situations where you want to perform bitwise comparison of structs too. This is OK. For the other situations where I use "==" among struts, I want it do the right thing, like comparing its contained strings correctly instead of arbitrarily choosing bitwise comparison of the sub-struct that represents the string. Making "==" work as "is" for structs means using an operator for the purpose of the other operator, and it has caused some bugs in my code. And it will cause bugs in future D code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




04:46:26 PDT ---

 This is an answer to Walter to Bug 7783 :
 

 In the absense of a user-defined opEquals for the struct, equality is defined
 as a bitwise compare. This is working as expected. Not a bug.
I agree, it's not a DMD implementation bug because here it's working as designed.
The statement above is not completely true: struct S { string x; bool opEquals(const ref S other) const { return x == x; } } struct T { S s; // no user-defined opEquals } void main() { T t1, t2; t1.s.x = "foobar".idup; t2.s.x = "foobar".idup; assert(t1 == t2); } This passes in 2.058. Essentially, bitwise comparison is done unless a member requires special case opEquals, in which case a generated opEquals function is made for that struct. I contend that for the compiler to defer to user-defined structs, but not to builtin types on how to compare themselves is not only inconsistent, but leads to endless boilerplate code. It does not help anyone. We have 'is', which does a bitwise compare. There is no reason to make == duplicate that functionality. For the rare cases where you actually *need* bitwise comparison on arrays or floats, you can define a special opEquals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




08:07:29 PDT ---
To further underline this point:

struct S {
    string x;
    bool opEquals(const ref S other) const {
        return x == x;
    }
}

struct T {
    S s;
    string r;
}

void main() {
    T t1, t2;
    t1.s.x = "foobar".idup;
    t1.r = "foobaz".idup;
    t2.s.x = "foobar".idup;
    t2.r = "foobaz".idup;
    assert(t1 == t2);
}

Yes, the string values in r are compared not bitwise, but for content.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




See also the thread:

http://forum.dlang.org/thread/jkpllu$1hss$1 digitalmars.com

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



12:36:15 PDT ---

 For the rare cases where you actually *need*
 bitwise comparison on arrays or floats, you can define a special opEquals.
Also hashes suffer from this problem as well. They're compared via 'is' instead of '==' in struct fields, just like arrays. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


jens.k.mueller gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens.k.mueller gmx.de




 Arrays don't have a an opEquals overloaded operator. What's the bug?
I don't understand. How can arrays have no opEquals yet this assert(bar.data == foo.data); compiles? Syntactically there is opEquals and it checks whether each element is equal to the corresponding other element. And the opEquals generated by default should for each member call opEquals if it exists. Otherwise it falls back to bit-wise equality. Why should it be different from this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



PDT ---
I just thought that I should point out that the correct behavior for comparing
structs is explained in section of 7.1.5.2 of TDPL (p. 258 - 259). It doesn't
explicitly discuss what happens with built-ins (it says that opEquals is called
on each of the members), but I would think that calling opEquals on each of the
members would mean using == on built-in types and _not_ bitwise comparison. So,
I think that it's pretty clear that the correct behavior is that the default
behavior of opEquals for a struct like

struct S
{
    T t;
    U u;
}

mean that the compiler generates an opEquals like (ignoring the issues with the
refness or constness of the argument or opEquals itself):

bool opEquals(S rhs)
{
    return t == rhs.t && u == rhs.u;
}

and that the types of T and U are completely irrelevant. If the compiler wants
to optimize it to being a bitwise comparison when that would result in exactly
the same behavior (save for performance differences), then great, but it should
_never_ do bitwise comparison when that would result in different semantics
from using == on each of the members.

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg gmail.com



2013-03-08 16:53:23 MSK ---
Just want to note the compiler often can't optimize a comparison to be bitwise
because of align gaps which also should be ignored to conform `opEquals`
behavior.

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




Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/3eecfd2b1e6d7b57affbe175ac252149371623e3
fix Issue 3789 - Structs members that require non-bitwise comparison not
correctly compared

https://github.com/D-Programming-Language/phobos/commit/b4f5c4f6dd8ec65b68528a246e17c1c46c346e29


Issue 3789 - Structs members that require non-bitwise comparison not correctly
compared

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
         Depends on|9671                        |



---
Partial fix for floating point, array, and union field comparison.
https://github.com/D-Programming-Language/dmd/pull/1731

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





 Partial fix for floating point, array, and union field comparison.
 https://github.com/D-Programming-Language/dmd/pull/1731
Associative arrays too? (The change log of the release should list exactly what parts of this bug are fixed and what is not yet fixed.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



10:47:33 PDT ---

 Just want to note the compiler often can't optimize a comparison to be bitwise
 because of align gaps which also should be ignored to conform `opEquals`
 behavior.
The holes must be initialized to zero, by definition, so that a bitwise comparison can be done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




2013-04-24 12:55:27 MSD ---


 Just want to note the compiler often can't optimize a comparison to be bitwise
 because of align gaps which also should be ignored to conform `opEquals`
 behavior.
The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.
Nop. Holes are holes, that's all. I'd be happy if it will be documented that padding holes must be zero-initialized. As for now we has the situation even worse than underdocumented (as always) C11, which partially defines it in "6.7.9 Initialization", para 10. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com






 Just want to note the compiler often can't optimize a comparison to be bitwise
 because of align gaps which also should be ignored to conform `opEquals`
 behavior.
The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.
Nop. Holes are holes, that's all.
Technically, D initializes all variables by first blitting T.init over them, which contains implementation defined values for the holes. "Thanks" to this, the implementation may make optimizations that makes assumptions on the values in the gaps. So even if you've initialized all the variables in a struct, if don't first blit the struct itself, your struct will be in a globally "not fully initialized" state. From there, an opEqual may fails, which would be legitimate undefined behavior. So even if "holes are holes", D's intialization mechanics mean they have defined values. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789






 So even if you've initialized all the variables in a struct, if don't first
 blit the struct itself, your struct will be in a globally "not fully
 initialized" state. From there, an opEqual may fails, which would be legitimate
 undefined behavior.
All D programmers need to keep this in account. The usage of std.array.minimallyInitializedArray is one of such cases. In D there is enough static introspection to statically tell if a struct has holes or not. So you can use this information to tell when it's safer to use uninitialized structs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




2013-04-25 12:00:28 MSD ---

 So even if "holes are holes", D's intialization mechanics mean they have
 defined values.
I don't see a fundamental difference between D and C here. D just initialize more stuff by default. IMO, it must be documented. Opened Issue 9988. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




---

 https://github.com/D-Programming-Language/dmd/pull/387
 Partial fix for floating point, array, and union field comparison.
 https://github.com/D-Programming-Language/dmd/pull/1731
The third try and fully fix this issue. https://github.com/D-Programming-Language/dmd/pull/1972 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




---

 The holes must be initialized to zero, by definition, so that a bitwise
 comparison can be done.
I think '==' operation should test structural comparison, not bitwise comparison. Only when structural comparison is equal to bitwise one, it can be optimized to the latter. By fixing issue 9873, struct objects comparison `s1 == s2` is rewritable to `s1.tupleof == s2.tupleof` for member-wise structural comparison. Compiler can apply this expansion recursively. struct S { int num; int[] arr; } struct T { S s; int[int] aa; } void main() { T t1, t2; t1 == t2; // is rewritable to: // t1.tupleof == t2.tupleof // t1.tupoelf[0] == t2.tupoelf[0] && t1.tupoelf[1] == t2.tupoelf[1] // t1.s == t2.s && t1.aa == t2.aa // t1.s.tupleof == t2.s.tupleof && t1.aa == t2.aa // t1.s.num == t2.s.num && t1.s.arr == t2.s.arr && t1.aa == t2.aa } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




---


 Partial fix for floating point, array, and union field comparison.
 https://github.com/D-Programming-Language/dmd/pull/1731
Associative arrays too? (The change log of the release should list exactly what parts of this bug are fixed and what is not yet fixed.)
I've supported AA member comparison in my third pull request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789




Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/42e929a12c4df7a68e7bc721479a36697abce67b
fix Issue 3789 - Structs members that require non-bitwise comparison not
correctly compared

Additionally fix interpret3.d tests, because class object equality is currently
not yet supported in CTFE.

https://github.com/D-Programming-Language/dmd/commit/596c1128f4de2b246d339497e1bcec70d93ffd78


Issue 3789 and 10037 - [TDPL] Structs members that require non-bitwise
comparison not correctly compared

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




07:03:51 PDT ---
Is this fixed now, and should I put it in the changelog?

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



---

 Is this fixed now, and should I put it in the changelog?
Yes I can say it is fixed, so close this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 12 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3789






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