AA key conversion woes

[Somedude]

Le 18/04/2012 15:30, SomeDude a écrit :
> On Wednesday, 18 April 2012 at 05:09:55 UTC, H. S. Teoh wrote:
> 
>> - Built-in reference types (pointers, refs, arrays) must be either
>>   tail-immutable, or the tail must be a struct or class (i.e., the user
>>   is allowed to use arrays of unqualified objects with custom toHash and
>>   opEquals as AA keys).
>>
>> This should allow the "nice" properties we can get from having the type
>> system enforce key immutability, for simple key types, and still allow
>> users to do complex stuff (define their own toHash/opEquals that ignore
>> parts of the object) when they need to.
>>
>> T
> 
> I'm not sure I got that part.
> 
> But for the rest, I tend to agree.
> Actually, it's how it's done in Java: the Object class from which derive
> all the other classes, has an equals() and an hashCode() method. Of
> course these methods can be overriden.
> http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html
> 
> 

I'm not sure I understood the whole issue and its implications, but
would this work: a map template that takes any parameter T as key AND a
lambda/anonymous/delegate function as a hash function ? Unlike Java,
passing the hash function avoids having to define a hashCode() and
equals() method for each class.

We don't impose any restraint on T, .keys would simply return T[], e.g
if T is immutable(int), .keys would be immutable(int)[].
I don't see the necessity for .keys itself to be an immutable array. I
even think it would be counter productive.