What's up with associative arrays, opCmp, opEquals and toHash in 2.066.0-b4. I'm trying to compile Tango with the latest beta and I'm getting this error:

"Error: AA key type TagIndex now requires equality rather than comparison"

Four months ago "opCmp" was added to "TagIndex" to fix some compile error in 2.065.0 and now it complains on "opCmp" being defined.

If I add "opEquals" it complains that I need to define toHash.

What exactly do I need to define to have a struct with two ints working as a key in an associative array?

-- 
/Jacob Carlborg

Jacob Carlborg:

> "Error: AA key type TagIndex now requires equality rather than comparison"

Hashing protocol has being finally fixed.


> What exactly do I need to define to have a struct with two ints working as a key in an associative array?

opEquals and opHash. But if your struct has only two ints as fields, it should work even if you don't define both methods.

Bye,
bearophile

On 7/21/14, 9:49 AM, bearophile wrote:
> But if your struct has only two ints as fields, it
> should work even if you don't define both methods.

Wat?

Ary Borenszweig:

> Wat?

Hash methods should be automatic for simple structs.

Bye,
bearophile

Am 21.07.2014 16:34, schrieb bearophile:
> Ary Borenszweig:
>
>> Wat?
>
> Hash methods should be automatic for simple structs.
>
> Bye,
> bearophile

That would be too much magic => special cases one has to know about.

Cheers,
Daniel

Daniel Gibson:

> That would be too much magic => special cases one has to know about.

What special cases? It works for POD structs. If you want a different hashing behavior (example: you want to ignore some fields), you define the two methods.


struct Foo {
    double x;
    int y;
    string s;
}

void main() {
    import std.stdio;

    bool[Foo] aa;
    aa[Foo(1.0, 2, "hello".idup)] = true;
    aa[Foo(1.0, 1, "hello".idup)] = false;
    aa[Foo(1.0, 2, "hello".idup)] = false;
    aa.writeln;
}


Outputs:

[Foo(1, 1, "hello"):false, Foo(1, 2, "hello"):false]

This was a very old large bug of D. Now it's fixed. Rejoice.

Bye,
bearophile

On 2014-07-21 14:49, bearophile wrote:

> opEquals and opHash. But if your struct has only two ints as fields, it
> should work even if you don't define both methods.

If the struct already has opCmp I need to defined opEquals and toHash?

-- 
/Jacob Carlborg

Jacob Carlborg:

> If the struct already has opCmp I need to defined opEquals and toHash?

From what I know, the new hash protocol requires toHash and opEquals. I think that now opCmp is not used by hashing. I don't know if you define just toHash and opCmp it uses opCmp as fallback.

Bye,
bearophile

On 7/21/14, 11:39 AM, Daniel Gibson wrote:
> Am 21.07.2014 16:34, schrieb bearophile:
>> Ary Borenszweig:
>>
>>> Wat?
>>
>> Hash methods should be automatic for simple structs.
>>
>> Bye,
>> bearophile
>
> That would be too much magic => special cases one has to know about.
>
> Cheers,
> Daniel

Ah, good. I though it only worked for structs with two ints :-P

On Mon, Jul 21, 2014 at 04:42:34PM +0000, bearophile via Digitalmars-d wrote:
> Jacob Carlborg:
> 
> >If the struct already has opCmp I need to defined opEquals and toHash?
> 
> From what I know, the new hash protocol requires toHash and opEquals. I think that now opCmp is not used by hashing.

Yes, finally that has been fixed.


> I don't know if you define just toHash and opCmp it uses opCmp as fallback.
[...]

I'm inclined to say, file a regression bug. If opCmp is defined but opEquals isn't, the compiler should auto-generate opEquals (as opCmp(...)==0).  Requiring the user to implement a separate opEquals when opCmp is already there is nonsensical, and opens the door to stupid bugs due to increased boilerplate. (Of course, if the user also defines opEquals manually, that's fine. But if he doesn't, the compiler should do the Right Thing(tm).)

In any case, if either opCmp or opEquals (or both) is defined, then toHash must be defined, since obviously the user doesn't want the default POD comparison implementation, and toHash must always be consistent with opCmp/opEquals otherwise the AA will break.


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.