[Issue 8561] New: Make xtoString, xopCmp and xtoHash detection just as tolerant as xopEquals detection

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8561

           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
        AssignedTo: nobody at puremagic.com
        ReportedBy: siegelords_abode at yahoo.com


--- Comment #0 from siegelords_abode at yahoo.com 2012-08-19 19:59:06 PDT ---
xopEquals is non-null for structs with widely different opEquals signatures,
e.g.:

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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------