Comment #0 by siegelords_abode — 2012-08-19T19:59:06Z
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.
Comment #1 by siegelords_abode — 2014-02-24T11:16:52Z
Now that opCmp is a requirement for associative array keys, this becomes even more dire.
Comment #2 by k.hara.pg — 2014-07-04T17:43:00Z
xopCmp case is mostly fixed in issue 10567.
For xtoHash case, I opened issue 13045.
Comment #3 by k.hara.pg — 2014-07-09T15:17:06Z
Unlike xopEquals, xopCmp and xtoHash, I think that generating xtoString for every types is not so valuable.
Comment #4 by robert.schadek — 2024-12-13T18:01:07Z