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.
