Rob Jacques <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #4 from Rob Jacques <>  2009-07-17 13:22:53 PDT ---
I was just bitten by this bug (porting some D1 code). However, switching 'int
opCmp(myStruct b)' to 'int opCmp(ref const myStruct b) const' fixed the issue.
So I agree this is a spec change and not wrong code generation.

The operator overloading documentation needs to be updated:
Both the example:
struct Pair
    int a, b;
    int opCmp(ref const Pair rhs)const
        if (a!=rhs.a) return a-rhs.a;
        return b-rhs.b;

And Text:
The parameter to opEquals and opCmp for class definitions must be of type
Object, rather than the type of the particular class, in order to override the
Object.opEquals and Object.opCmp functions properly.

The opEquals and opCmp definitions for structs must be of type const and the
parameter must be of type ref const in order for array sorting or associative
array key ordering to work properly.

Array documentation needs to be updated:

For the .sort property to work on arrays of structs or unions, the struct or
union definition must define the function: const int opCmp(ref const S). The
type S is the type of the struct or union. This function will determine the
sort ordering.

Note that none of the following work:
int opCmp(ref const myStruct  b)
int opCmp(    const myStruct* b) const
int opCmp(    const myStruct  b) const
int opCmp(    const myStruct  b) 
int opCmp(          myStruct  b) const
int opCmp(          myStruct  b)

As this issue causes D1 code to silently fail when ported to D2, it might be
justified to add a compiler warning when a struct contains an incorrect opCmp
function, similar to the runtime error that occurs when opCmp(MyClass c) is
defined instead of opCmp(Object o).

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to