@nogc hash

[Marco Leise via Digitalmars-d]

Am Fri, 09 Sep 2016 11:35:58 +0000
schrieb Guillaume Piolat <first.last at gmail.com>:

> On Friday, 9 September 2016 at 11:16:19 UTC, Marco Leise wrote:
> > It does not /allocate/ with the GC, but the methods are
> > not /annotated/ @nogc, e.g. insert():
> > https://github.com/economicmodeling/containers/blob/master/src/containers/hashmap.d#L338
> > It's plain simple not possible out of the box* at the moment.
> >
> > * writing your own hash function that covers every type is NOT
> >   "out of the box" :p  
> 
> But they are template functions.
> Maybe this is a case of 
> https://p0nce.github.io/d-idioms/#Automatic-attribute-inference-for-function-templates then?

Sorry, I didn't want to talk about the lack of attribute
inference for non-templated functions inside templates :p.
Yes, that's why some of the methods in EMSI containers are
annotated and I'm aware of that.

The point is that TypeInfo_*.getHash() cannot be @nogc,
because a class or struct may implement a not- at nogc toHash().
(Where I may add, that e.g. TypeInfo_Pointer.getHash() *could*
be @nogc, since all it returns is `cast(size_t)cast(void*)p`).

The alternatives in core.internal.hash are supposed to
be CTFE-able and albeit bytesHash itself does not seem to use
the GC, the wrapper functions for different types may.

And that is why @nogc hash table implementations don't fly at
the moment.

-- 
Marco