About built-in AAs

[bearophile]

Sean Kelly:

>This would be a run-time issue, unless you're asking the compiler to verify your hash algorithm at compile-time :-p  I'd actually like to have some introspection functionality so I could find out the average chain length, max chain length, etc (basically what's provided by the unordered containers from C++11), but the user would still have to query this stuff to know that something was wrong.<

What you are talking about is interesting. But I was asking in the point 1 of my original post is something different and simple, it's a fully static thing.

This was my original post of this thread:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=142709

What I was asking in that point 1 is:
1) If the user writes wrong signatures for the each of the methods needed for the hash protocol (currently they are toHash() opEquals() and opCmp()), then I'd like the compiler to tell me with a compile-time error. I think DMD is already mostly doing this.

2) If the user adds a toHash method to a class or struct, then the compiler must statically require the presence of all the other methods needed by the hash protocol. Currently DMD is not doing this, if you add correct toHash() and opEquals() methods, the compiler will silently not use them. I think this isn't acceptable in a good language.

--------------

In the successive points of my original post I have asked two other things: pushing AAs to a fully templated implementation, and totally remove the need of a opCmp from the hash protocol.

--------------

Extra:

I presume there is no way to ask (on request) the language to use a stack-style memory allocator for the built-in AAs instead the normal GC. But once built-in AAs are fully templates I presume it's not too much hard to give an interface to them from Phobos functions too. So now it's possible to let this use a different memory allocator.

Bye,
bearophile