On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer
wrote:
On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via
Digitalmars-d <[email protected]> wrote:
On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer
via Digitalmars-d wrote:
On Sat, 24 May 2014 02:54:01 -0700, FG <[email protected]> wrote:
[...]
>Really? Then what does TypeInfo.compare(void*, void*) use?
>For
>example here:
>
> auto key_hash = keyti.getHash(pkey); Entry *e;
> /* ... */
> if (key_hash == e.hash) {
> auto c = keyti.compare(pkey, e + 1);
> if (c == 0) goto Lret;
> }
You know what, you are right. I assumed it used keyti.equals.
This is
a bug imo, since opCmp will be used, and opEquals will be
ignored.
Just checking for opCmp == 0 is identical to opEquals, except
some
types can define opEquals but not opCmp.
But I don't know if it will get fixed. The whole AA runtime
has to be
redone at some point.
[...]
This has been argued over in a druntime pull before. I'm 100%
for
changing the above line (and all other instances of it) to use
keyti.equals() instead. But that was shot down due to
potential breakage
of existing code. :-( :-( Nevermind the fact that it probably
breaks a
lot more *new* code than it ever will break old code... :-(
Any object/struct that defines opCmp but not opEquals is
broken, and deserves to not work with AAs.
It's a trivial change to add opEquals when opCmp is defined.
-Steve
Perhaps I'm being naïve, but can't we just have a default
compiler generated opEquals iff opCmp is defined and opEquals is
not.
