www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12255] New: Regression: opCmp requirement for AAs breaks code

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

           Summary: Regression: opCmp requirement for AAs breaks code
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bugzilla digitalmars.com



11:41:32 PST ---
http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih

The pull request that did it:

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

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 25 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12255


Steven Schveighoffer <schveiguy yahoo.com> changed:

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



14:00:30 PST ---
First, AAs should use equals instead of compare. At the moment, it uses
compare(a, b) == 0, which should be equivalent to equals. Also note that some
structs may be able to compare via equality, but not ordered.

Second, I believe only struct keys which satisfy one of the following two
conditions should be allowed:

1. Neither opCmp nor opEquals are defined.

Rationale: If neither opCmp nor opEquals are defined, then equals(a, b) is
guaranteed to be equivalent to compare(a, b) == 0, since the compiler generated
the functions. Note that this applies recursively in the case of member structs
if the compiler is generating the function.

2. Both opEquals and toHash are defined.

Rationale: if opEquals is specially defined, then toHash must also be specially
defined. If opEquals only examines part of the object, then toHash would have
to be modified to only examine part of the object as well.

All other structs should be disallowed as keys.

Rationale: Only opEquals will be used for comparison. If one defines opCmp but
not opEquals, then the builtin opEquals may not be equivalent to opCmp() == 0,
and the AA will not use the correct comparison tool.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 25 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12255


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob me.com



08:07:45 EET ---
*** Issue 12267 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12255


Vladimir Panteleev <thecybershadow gmail.com> changed:

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



22:51:39 EET ---
From issue 12267:

This program no longer compiles:

struct S {}
int[S] aa;

However, it will compile if you add this to the top of the file:

struct T { int opCmp() { return 2; } }

It looks like an opCmp in ANY struct will unbreak compilation (as long as it
comes before the AA).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 27 2014