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


Steven Schveighoffer <schvei...@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schvei...@yahoo.com


--- Comment #2 from Steven Schveighoffer <schvei...@yahoo.com> 2010-09-16 
06:10:07 PDT ---
Some more info about how the runtime deals with struct "polymorphism" and opCmp
and toHash etc.

In TypeInfo_Struct, there are the following function pointers:

http://www.dsource.org/projects/druntime/browser/trunk/src/object_.d?rev=376#L930

The compiler sets these if you define the appropriate functions with the
correct signatures.

Then the runtime uses the TypeInfo.compare function to compare two values, or
TypeInfo.getHash.  The TypeInfo_Struct overrides these functions to check if
those function pointers are valid, and if so, call them to compare two values. 
Otherwise, it does a bit-compare.

Any runtime function that uses these functions (including array sort) will be
affected.

I disagree that the compiler should reject opCmp if it doesn't match the
special signature, opCmp is simply a function.  There are valid uses of opCmp
that do not match the signature.  For example, the compiler currently requires
struct opEquals to have a signature of

bool opEquals(ref const(T) other) const

Which means you can't compare two rvalues (bug already filed).  This is the
mess that will occur if you start requiring special signatures for all the
others.

However, I think it would be good to add an attribute indicating that the
compiler *should* reject the function if it doesn't match, as bearophile
suggests.  However, I think it should be an @attribute, not a keyword.  My
suggestion is @typeinfo to signify that this function belongs in the typeinfo.

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

Reply via email to