Summary: Make xtoString, xopCmp and xtoHash detection just as
                    tolerant as xopEquals detection
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD

--- Comment #0 from 2012-08-19 19:59:06 PDT ---
xopEquals is non-null for structs with widely different opEquals signatures,

bool opEquals(const ref S s);
double opEquals(S s);
auto opEquals(T)(T t);

all lead to a non-null xopEquals. This is because a new static function
(__xopEquals) is generated which calls the struct's opEquals. I think the same
should be done for all other functions. Here's a use case: Say we have a
variant struct type and we want to implement an opCmp in it. Phobos's variant
does this:

int opCmp(T)(T rhs)

This leads to a null xopCmp entry. To get a non-null xopCmp entry we can use
this ugly workabout:

int opCmp(const ref variant v); //This one will be picked up by the xopCmp
detection code
int opCmp(...); //This one will be used for all other types

With a more tolerant xopCmp the original templated opCmp would work just as
well. I don't have a real use case for a more tolerant xtoString and xtoHash,
but I'm sure someone can think of an example where you want those to be
templated/have a parameter.

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

Reply via email to